Brace Style for Older Languages

utzoo!decvax!harpo!eagle!cw utzoo!decvax!harpo!eagle!cw
Fri Oct 29 18:44:29 AEST 1982

A snide insinuation about FORTRAN was recently made in this
group: namely, that its brace style was to use GOTO's.
No longer true, to wit:

	1.  FORTRAN 77 explicitly includes IF-THEN-ELSE-ENDIF.
	    This solves the bracketing problem explicitly.

	2.  FORTRAN ?? is likely to include similar constructions
	    for all the other control structures.

Two points should be made.  First, I have programmed extensively
in a FORTRAN with IF-ENDIF and the number of GOTO's dropped 
dramatically.  There were still a few deep loop error escapes;
GOTO is also used in C for this purpose.  Otherwise, GOTO's
were mostly restricted to jumping back to the heads of 
(unfortunately hand-made) while loops.

Second (and this is inflammatory), I do not understand how anyone
can defend the use of braces when ALGOL 68 showed us the way to
use explicit closers on all grouping constructs.  It is one of the
syntactic things dislike most about C and I try to write all
grouping statements with macros in my coding so that I know what
goes with what.  The questions of DO-OD versus LOOP-END LOOP
should not keep us from recognizing the power of this simple idea.

On the other hand, if we must put up with braces, I welcome
this discussion of how they may best be used.  I would like to
second the words of those who argue for more light and less heat 
on the subject.  The goal of programming style standards is not to
force everybody everywhere to code the one best way; rather, it
is to make sure that each individual file, program, project, or
what have you is internally consistent and understandable.  Remember that
the commandment for programmers is


The reason: otherwise the program reader will try to figure out why
you changed.  Of course, you had no good reason; the change was just a
random and harmless permutation.  But the reader doesn't know that.

By the way, while I had a lot of experience in FORTRAN, no one
should thereby be mislead into believing I liked it.


More information about the Comp.lang.c mailing list