questions from using lint

Kenneth Almquist ka at hropus.UUCP
Wed May 14 05:44:33 AEST 1986


> Yet another convention, not endorsed by any language I know, is to dispense
> with the braces and let the indentation alone tell the compiler how to
> interpret the program.  (I came up with this idea after an argument on the
> "correct" place to put the braces.)

I first encountered this idea about 8 years ago, when Dave Korn used it
in a specialized language for data checking, and it is a good one.

Using braces to indicated the structure of a program results in code that
is quite difficult to read.  (Try removing all indentation from any C
program you choose and see how readable the result is.)  Of course
sensible programmers use indentation to indicate the structure of the
program to the reader.  So from the reader's point of view braces are
just useless clutter.  Thus the C language forces the programmer to use
two separate methods of indicating the structure of the program, one for
the benefit of the reader and the other for the benefit of the compiler.
Given that the compilers can fairly easily be written to understand
about indentation, there is no justification for requiring programmers
to translate the indentation information into brace form by hand, with
the attendent risk of errors.

Furthermore, Jim has correctly pointed out that the braces actually
obscure the code for the human reader, since they add clutter without
providing any new information about the program.  In fairness, C is
better than most languages in this respect since it reduces begin and
end to single characters.  This is good enough that I do not agree with
the extremes to which Jim goes to avoid braces.  But C doesn't take the
idea to its logical conclusion, which is to eliminate the delimiters
entirely.

Fortunately, grouping by indentation has finally been adopted by at least
on language.  See the article on "Modcap" in the March issue of Sigplan
Notices.
				Kenneth Almquist
				ihnp4!houxm!hropus!ka	(official name)
				ihnp4!opus!ka		(shorter path)



More information about the Comp.lang.c mailing list