Now, isn't this rendition of the example given earlier **MUCH** easier to
read, parse, and understand?...
switch (key) {
case BACK:
fprintf(stoout,"BACK\n");
if (device->s.stroke.current_editpos > 1)
{
device->s.stroke.current_editpos--;
for ( device->s.stroke.editptr = &(device->s.stroke.header),
i = 1;
device->s.stroke.editptr->next->next,
i < device->s.stroke.current_editpos;
device->s.stroke.editptr = device->s.stroke.editptr->next,
i++ )
{ /* NADA */ }
}
Note: Braces on new line, indented by one, with code indented by another two.
Continued statements indented to level of original statement. Perhaps
something could be done to separate the FOR clauses that end with comma from
the FOR clauses that end with semicolon. I haven't been programming C long
enough to have done enough of these complex statements to have evolved a
programming style for them.
Now, come on. K., R., et al done did something really neat in coming up with
C and Unix, but they don't walk on water nor were they a result of virgin
birth. They did an awful lot of things right, and they did a few things very
very wrong. Making tab stops every eight was very very wrong. I'm sure they
didn't waste a lot of time thinking about it, they just had a bunch of DEC
hardware around and decided to use what they had. Note if you were to
trivially modify the above to indent 1 and 3 rather than 1 and 2, every other
indent would line up with a tab stop and you could (sort of) have the best of
both worlds.
And (as long as we are sharpening axes here) if you were programming in
PASCAL you could put the sucker in a WITH DEVICE clause and get rid of all
those "device->" references. AND, it would be more efficient since the
reference would only be evaluated once, at the WITH clause (clearly compiler
optimization in C compilers would have a bearing on this).
--
Ben Cranston ...{seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben zben at umd2.ARPA