Coding Standards.

Steve Summit scs at adam.mit.edu
Sat Dec 8 03:36:17 AEST 1990


In article <1990Nov30.180913.20890 at clear.com> rmartin at clear.com (Bob Martin) writes:
>...it is seldom the case that a reasonable
>identifier cannot be tacked onto a closing brace. 
>The alternative of not demanding the comments on closing braces
>exposes you to the danger of a function that has grown to span
>(god forbid) multiple pages and has no comments telling you where
>the braces line up.

Not to argue with you, but just to present an opposing
viewpoint, I've always felt that "} /* end if */" and the like
make code look like it was written by amateurs who are still
shaky on mere syntactic details.

Good programmer's editors have "show matching brace" commands
which work well in those cases when the code layout doesn't make
brace matching obvious (or, as you point out, when long blocks
span pages or screens).

I suppose a comment would help when you've got

						}
					}
				}

			/* some cleanup code here */

			}
		}
	}

and it's important to know which block(s) have just been exited
and which block(s) the cleanup code is still in.  However,
rule-based /* end if */'s and /* end for */'s would in this case
only be a partial solution, since they would require the reader
to search back to find the opening if or for to discover the
purpose of the blocks being left (resp. blocks still in).
This search would require a brace-matching editor, or careful tab
counting, if there were several if's and for's in the blocks
being searched.

Comments like /* end of ^C special case */ or /* end of argument
parsing loop */ could be useful.  Perhaps that is what your
standard requires.  I should think, though, that comments like
these (as opposed to their less-useful brethren /* end for */ and
/* end if */) would be better requested with a rule like "code
shall have useful comments" (perhaps with hints like "...such as
at the beginning (and end) of complicated blocks") than by simply
declaring that "all closing braces shall have comments."  (Again,
perhaps your standard does say something like the former; I
haven't seen it.  It is admitted, too, that rules like the latter
are, while less useful, much easier to enforce.)

                                            Steve Summit
                                            scs at adam.mit.edu



More information about the Comp.lang.c mailing list