Standard Indentation etc.

[Mark A Terribile]

> >>...8 columns is _way_ too big for an [indent].  The range recommended by
> >>everyone except C let's-torture-test-the-eyes hackers is two to five ...

> >8 columns is just fine for people who split up their code into functions
> >instead of cramming it all into giant monolithic lumps.  ...

> ...  My point is not that code runs off the right margin.  ... 8 columns
> columns is just too big a jump for the eye.  ...  I had never seen anyone
> use indent-by-8 before I met C:  good Fortran programmers used 2 to 5, good
> COBOL programmers used 2 to 5, good Algol programmers used 2 to 5, good
> PL/I programmers used 2 to 5, good BCPL programmers used 2 to 5, ...

At one time, good house paint was based on lead white.

I don't find 8 columns to be torture for the eyes.  Indeed, I find anything
much less to be hard to see.  Perhaps it's because I like to lean back and
take the long view ;^}  I *do* have code running off the far margins, in
part because I use moderately long identifiers, in part because I use plenty
of white space in line, and in part because I use the expression syntax of
C (and of C++, whose expression syntax is even more potent) for all its worth
*WITHOUT* becoming obscure.  This means that I must split lines; I split them
at points that are clearly NOT indentation columns--unless I am writing
something like

	printf( format,
		key_p->mark,
		key_p->instances == 1 ? "" : "s",
		key_p->descr->use,
		Camb_TYPENAME( key_p->descr->type ),

    etc.

A better question is why other languages use such small indents.

In FORTRAN, of course, it's rare to see 200 lines of 10-line functions; in
C it can be fairly common.  The larger external compilation units will call
for more levels of indentation.  Moreover, up until recently, the FORTRAN
``do'' was brain-damaged and had to be protected by an ``if'' from looping
once when it should loop zero times.  Programmers who wrote that as two levels
of control structure would end up with a double-indent; programmers who
considered it a single (synthetic) control structure would write it as one.

The problem of formatting ``synthesized'' control structures infects other
languages as well; a pass through *The Elements of Programming Style* will
show all sorts of trouble that people have made for themselves in this way.

Pascal is a special case; its small-minded expression syntax and control
structures are unexampled in languages written by people who ought to know
better.  (Yes, I'm flaming.)  The inability to write short-circuit evaluations
and to accomplish even modest operations like assignment inside tests forces
multiple levels of ``if'' and redundant ``else'' clauses.  Moreover, it
forces natural operate-and-test-at-the-top loops into operate, test, set
flag, if-not-flag, test-at-bottom constructions.  Often three or four levels
are needed to synthesize one control structure.  The inability to do an early
return also forces cases to be nested in if-then-elses, and the rote approach
to control structure encouraged by the mess leads people to mindlessly indent
else-if's whether it reflects the nature of the problem or not.

I can't speak for Algol (which one?) or BCPL, but PL/I's label-directed
syntax and lack (in most versions) of early exit encourage or force the
same problems of synthesized control structures that plague FORTRAN; when
PL/I is used for ``FORTRAN with semicolons'' the problem is even worse.

COBOL is a world unto itself; even the people who continue to use it and
specify it wish they had something better that ``felt'' like good old familiar
COBOL and had all of the indispensible arcana that COBOL supports.  It's
hardly an universal example of programming style.

Small indentation is an irritating solution to a family of problems that C
just does not have.  Why carry it around?

Of course, if you are using a screen whose typeface is so poor that you have
to lean 5'' close to it to read your program, then the 2-space indent is
easily explained ;^}
-- 

(This man's opinions are his own.)
>From mole-end				Mark Terribile