Xref: utzoo comp.lang.c:14782 comp.unix.wizards:13479
Path: utzoo!utgpu!attcan!uunet!ingr!crossgl
From: crossgl@ingr.com. (Gordon Cross)
Newsgroups: comp.lang.c,comp.unix.wizards
Subject: Re: Standards (was Re: indentation:  enough already!)
Message-ID: <3245@ingr.com.>
Date: 14 Dec 88 15:15:35 GMT
References: <3229@ingr.UUCP> <253@athertn.Atherton.COM>
Reply-To: crossgl@ingr.UUCP (Gordon Cross)
Organization: Intergraph Corp. Huntsville, Al
Lines: 57


Regarding my posting on the "indentation" debate:

In article <253@athertn.Atherton.COM> paul@athertn.Atherton.COM (Paul Sander) writes:
>
>Your points are well taken, and I admit I agree with them to a degree.  But
>let me quote from DOD-STD-2167A, Military Standard, Defense System Software
>Development:
>
>   [lengthy excerpt deleted]
>
>So it would seem that for many of us (especially those who work for
>government contractors), coding standards are there and will not go away.

Well, well.  At last I've learned something new!!  I wonder how many MILLIONS
OF DOLLARS (of your money as well as mine) the government is spending on this
stuff.  Think about the savings if the government would just keep their hands
out of the pot and let the defense contractors deliver the finished product!!
What should they care so long as it works??!!!  As an end user of something
like "ksh", I couldn't care less about the style of the source code because
the program works.  No wonder no one can balance the budget:  it would most
likely cost more than the deficit is to balance it!! (typical bureaucratic
mentality)

>There are good reasons for standards; the biggest one is, of course, that
>code written to some standard is easier for someone else to understand,
>provided he/she also knows the standard.  Keep in mind that "someone" may
>be any of up to several hundred people who may be working on a project.
>Experience has shown that having 200 subtly different coding styles on the
>same project when it gets into the maintenance phase raises many more problems
>(the least of which is individual productivity) than coding standards do
>during the design and implementation phases.

OK, you do raise a good point here, but allow me to state my case.  The
company I work for does not impose such restrictions (although I don't know
about the Federal Systems Division based on want you said about the
government).  I have on numerous occasions had to correct "bugs" in other
people's code.  In doing so, I found that the majority produced very readable
and well documented code.  Although each person clearly had his/her own 
coding style, the similarities were quite remarkable.  Any programmer at all
knowledgable about the C language should not have that much difficulty
deciphering other coding styles.  On the flip side, I must admit that I
have also seen some VERY poorly written code (no comments, one letter global
variables, etc).  The point I am trying to make here is that left alone good
programmers write good code and bad programmers write bad code.  What is
needed instead of stringent "standards" is a well thought out education plan
whose goal is to make good programmers out of bad ones...

>Please accept my appologies for the long posting, and for drifting so far
>away from the original subject.

Apology accepted.


Gordon Cross
Intergraph Corp.  Huntsville, AL
...uunet!ingr!crossgl