The great indentation debate continues!! (long)
Gordon Cross
crossgl at ingr.com.
Sat Dec 17 05:12:34 AEST 1988
I just knew that my original posting was a mistake since I definitly did
NOT want be drawn into this discussion. But apparantly this event has
transpired and I regretably must respond to the fire as the flames are
spreading :-) :-). Many of you have interpreted may rantings and ravings
on this subject to mean that I am advocating bad, unreadable, and
unmanageable code writing. This cannot be farther from the truth. I am all
for good, well documented, easy to read and understand coding styles. What
I am against are requirements specifying these picky picky details such as
"you must indent precisely two (2) spaces", "you must indent precisely
one (1) tab stop", or "the { and } must be on a line to themselves and line
up vertically". I could sit here and list examples ad infinitum but I won't.
If a style standard will produce the kind of code everyone is obviously
looking for, then I will be for it. BUT, the standard MUST be flexible
enough not to unjustly cramp a programmer's creativity. For example it
should allow any of the following popular styles:
while ( <expr> ) { while ( <expr> ) while ( <expr> )
statement1; { {
statement2; statement1; statement1;
. statement2; statement2;
. . .
} . .
} }
These are only a sampling of the many excellent choices available. OK down
to business and specific responses:
-------------------------------------------------------------------------------
In article <251 at twwells.uucp> bill at twwells.UUCP (T. William Wells) writes:
>: Back in my school days, one professor tried to enforce his indentation style
>: on the class (you could lose up to 25 points for violations!!).
>
>Good for him!
>
>: I in
>: addition to others found "his" style impossible to work with and quickly
>: reverted to our own.
>
>And what made you feel that yours was any good? Weren't you in his
>class to learn?
All right you asked!! :-) And to satisfy your request, I went home and
rumaged through my old school work and I found it: the required style of
the professor in question. The whole thing is WAY too long to type in here
so I give some examples of what he wanted. You tell me: how does this
"style" rate for readability and ease of use!!
I. while loops
--------------
while ( expr ) { statement1;
statement2;
.
statementN; }
II. do loops
------------
do { statement1;
statement2;
.
statementN; } while ( expr );
III. if statements
------------------
if ( expr1 ) { statement1;
statement2;
.
statementN; } else
if ( expr2 ) { statement1;
statement2;
.
statementN; } else
{ statement1;
statement2;
.
statementN; }
Opinions? Good or bad? How 'bout that there if-else construct?? By the way
he insisted that you do not wrap lines without taking advantage of full 132
character wide printout capacity (and with this it happened almost 100% of the
time!!!!!). Makes it difficult to edit on an 80 character terminal (the
terminal could display 132-wide lines but the editor would always assume 80...
SOL!)! And since you were constantly wrapping lines, a complex routine
quickly became a real jumbled mess... (he spelled out how to wrap lines also.
if anyone wants to how how he wanted this done: ask)
>Boo! Fire the dean! "... those who can't teach, administrate" seems
>to describe him all too well.
Seems to me that this professor has a problem with teaching as well. I wonder
how many of his students are coding in that ridiculous style right now because
they didn't have the gumption to question what they were told. Not taking
as gospel what someone tells you is right is perhaps THE most important
aspect of learning!!
>Don't apply to Proximity (the company I work for) for a job, you
>won't get one. We have several *very* good C programmers. We all code
>to the same standard. Our existence disproves your belief.
Hummmph! If everyone else at your company is as rude as you are I wouldn't
want it. This statement deserves no further comment....
-------------------------------------------------------------------------------
In article <103 at adobe.COM> burgett at adobe.COM (Michael Burgett) writes:
>
> As a (very happily) former employee of a company that did ONLY government
>contracts, it's obvious that you don't know the first thing about this
>field, nor have you given the area any thought.
On this you are indeed wrong!! My first job was with IBM working on a
government contract relating to the Trident submarine. The standards we used
were not as harsh as the one Paul Sander posted excerpts from. In fact the
stuff was not written in "C" but a Navy language called CMS-2Y.
> A government project has to be coded to standards set by the government so
>that when it is code reviewed (by government QA types) it can be easily read
>and understood, even if the people who coded it are no longer responsible for
>the project (quit, fired, defected, abscounded to argentina, take your pick)
Yes!!! But "easily read and understood" should not be construed to mean
"there must be EXACTLY this much white space here (or whatever)". Our code
was reviewed by QA types. We had weekly "code inspections" in which the
group would agree on how to correct any area of hard to follow code. Almost
NEVER was "hard to follow" attributed to someone's indentation style. The
most common were lack of comments, confusing comments, bad variable names, etc.
>But that's right, why should they care as long as it works.... Gee, let's see
>if we carry that philosophy over to the software that controls the detection
>of enemy missle launches and our retalitory launches... hmmm. I guess you'd
>like to leave that in the hands (unchecked) of the contractor that got
>picked for the job??
You seem to be reaching here! :-) Do you really believe that I (or anyone)
would put untested software into operation?? Our code was subjected to tests
so strenuous that it took 2-3 weeks to run them!! Never (while I was there
anyway) did a major bug escape detection in these tests.
>Also the defense contractors would love to go your route, cause some of the
>unscrupulous ones (those fine pillers of society :-)) might actually be
>tempted to code an initial project in such a way that might make it real
>tough to award the maintenance contract on the software to someone else....
Again you are accusing me of advocating bad code. Yes, the code should be
inspected as it was and still is. Looking back at my original (harshly
written) posting, I see how you might arrive at this conclusion. The
"throughout eternity" comment was my reaction to the thought of someone
legislating my code simply because it does not conform to that someone's
idea of "pretty"...
-------------------------------------------------------------------------------
In article <4402 at pbhyf.PacBell.COM> mche at pbhyf.PacBell.COM (Mitch Che) writes:
>
>Left ALONE, 50 programmers will come up with 50 different reasons why
>the other 49 programmers should do it THEIR way.
I've never seen this happen. The programmers I know would never abuse their
co-workers in such a way. It makes for a hostile work environment with little
work and lots of arguing!
>Education is necessary. Unfortunately, many times the ones who are
>most educated, the "experts", regress and become "bad" programmers.
>A story: In a previous job, I worked with Fortran and APL. The
>expert programmers would compete to come up with the longest Fortran
>program in the world that could be converted to one line of APL. The
>result was typically something so obsure that even the author couldn't
>figure out what the APL code really did without the Fortran code. If
>we'd had standards for APL, perhaps they would have included something
>like, "Even though we KNOW you can do it and it's CLEAR as a BELL to
>you, do NOT put more than the equivalent of 100 Fortran statements on
>1 line of APL." half a :-) Only experts can do this and they, of
>course, know everything and are most likely to want to be left alone.
These types seem to be on some sort of ego trip demonstrating that they
know all the abstract nuances of the language. The Fortran/APL contest
you mentioned is just fine for a little personal challenge, but these people
(hopefully) know better than to put such stuff into delivered software.
If they did, I would lump them into the "bad programmers" catagory.
>Standards are imposed on workers for other people, not the people
>doing the work. People with engineering backgrounds who look at some
>"standards" for programmers would be happy to deal with these rather
>than what they have to put up with. Most standards for programmers
>are trivial, e.g. stylistic. Programmers who can't follow these, and
>complain about impacts on creativity and productivity should be forced
>to comment the code of 50-60 programmers for the benefit of the
>nearest maintenance group.
Requiring that programmers comment their code has nothing to do with what
I've been objecting to. Those 50-60 programmers who didn't comment their
code should be the ones required to do so.
-------------------------------------------------------------------------------
In article <9190 at smoke.BRL.MIL> gwyn at brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>
>No, it doesn't; it has bugs. What should the customer do if one of the
>bugs simply HAS to be fixed? Remember that in the government's case, it
>owns the deliverables (source code, etc.) and is responsible for fixing
>the bug itself (which it might do by an additional contract). Certainly
>maintainability of the delivered product is a valid requirement. What
>is wrong is the particular way the regulations attempted to achieve
>maintainability (by legislating coding style).
Here here!!
AND NOW AS A FOOTNOTE: I hope I have managed to clear up the confusion about
what it was that I was advocating and what I was objecting to. I have my own
personal indentation style and so do you; but I would NEVER dream of forcing
you to use mine...
P.S. As of tomorrow (Saturday) I will be on vacation for two weeks much to
the joy of some of you :-) :-) :-). Bye for now!!!
--
Gordon Cross UUCP: uunet!ingr!crossgl "all opinions are
111 Westminister Way INTERNET: crossgl at ingr.com mine and not those
Madison, AL 35758 MA BELL: (205) 772-7842 of my employer."
More information about the Comp.lang.c
mailing list