🚀 go-pugleaf

In article <druhi.2684> kam@druhi.ATT.COM (MorrisseyKA) writes:
>
>Uniform style is important at all scopes: within a single program,
>within a project, or within a company.  Differing styles, especially
>within a single program, will make it more difficult for others to
>understand the program.

I strongly disagree with this statement.  Many years back I was part of a
FORTRAN 77 compiler development team.  My job was to test and correct the
compiler.  The compiler consisted of ~100,000 lines of PL/6 code, written
by 8-10 different people.  One other person was supposed to do the same as
me.  6 of the 10 people were top notch programmers with beautiful coding
style, but the styles were completely different.  The other 4 programmers
varied in skill from good to beginner.

When it came right down to it, picking up a routine written in one style
and then switching to a different routine written in another style was no
problem if both styles were good.  (I had to look at everyone's code, so
I had *a lot* of opportunity to do just that.)  It didn't matter how
radically different the two styles were.  Problems arose when #1) the
style was poor to begin with, or #2) it was not consistently adhered to.

Poor style meant things like:

	too much or too little indentation,
	indentation schemes which were complicated,
	failure to use blocks on control structures (e.g. if, while)
	breaking lines in wierd places,
	heavy use of goto statements,
	routines or modules which were too long,
	excessive global variables,
	non-descriptive variable names,
	names which were similar to or easily confused with other names,
	sparse comments,
	comments which were english translations of the code they were
	commenting (e.g. i = i + 1; /* add 1 to i */),
	etc.


When the style was not consistent, it was often for one of several reasons:

	More than one programmer had worked on the file and subsequent
	programmers had not been careful to retain the original style,

	The style was too complicated, and hence confusing even to the
	author,

	The programmer had no real concept of style, and simple indented
	when he "felt like it".

>Even arbitrary standards are beneficial.  A standard does not need to
>be the best. Who can even say what best is?  The value of standards is
>that they are shared.

Standards may be very strict to the point that they are enforced by the
compiler (as in Occam), or they may be no more than general guidelines
similar to the ones I have given above (but perhaps more complete and
precise).  I am against the more rigid end of the spectrum.  But I also
realize that such things may be needed where programmers are more inclined
to write amorphous code.

I would rather see minimum standards for readibility than have everyone's
code look the same.  Strict standards would require time to be spent
enforcing them (standards which are not enforced are not standards) which
might be more productively used elsewhere.

>Karen A. Morrissey
>1-303-538-4587
>ihnp4!druhi!kam
--
Doug Pase  --  ...ucbvax!tektronix!ogcvax!pase  or  pase@cse.ogc.edu (CSNet)