Standards (was Re: indentation: enough already!)

[Paul Sander]

In article <3229 at ingr.UUCP>, crossgl at ingr.UUCP (Gordon Cross) writes:
> 
> [Flames about uselessness of this discussion deleted]
>
>                                                                         My
> feeling on this matter is that ANY programmer will ALWAYS be most productive
> without artificial restrictions on mundane things as indentation "standards".
>
> [College story about professor specifying coding standard and the Dean's
>  intervention deleted]
>
>                                               We should all take heed and
> learn a lesson from this!!  As for me, regardless of "standards" I will
> continue to code using MY style throughout eternity...
> 

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:

Appendix B

Requirements for Software Coding Standards

10.1  Purpose.  [Purpose deleted]  The requirements specified in this
appendix are a mandatory part of this standard.

10.2  Applicability.  This appendix applies to all deliverable source code
developed under the contract.

10.3  Rules and Conventions.  The following subparagraphs define the
requirements for rules and conventions applicable to software coding
standards.  The contractor shall implement coding standards that comply
with these requirements.

10.3.1  Presentation style.  The coding standards shall descripbe the
rules and conventions for the format of the source code [lists source
code media].  The rules and conventions for presentation style shall
include standards for:

a.  Indentation and spacing
b.  The use of capitalization
c.  Uniform presentation of information throughout the source code...
d.  Use of headers
e.  Layout of source code listings
f.  Conditions under which comments are provided and the format to be used
g.  Size of code aggregates...

10.3.2  Naming.  ...

10.3.3  Restrictions on the implementation language. [i.e. restrictions on
features of the implementation language that may be used]

10.3.4  Use of language constructs and features. [i.e. describes how
features of the implementations may be used]

10.3.5  Complexity.  The coding standards shall describe controls and
restrictions on the complexity of code aggregates.

---

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.

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.

Even if a project is not governed by DOD-STD-2167A, coding standards are
useful for improving the reliability and maintainability of programs.
Requiring descriptive function headers and lint checks work wonders once
the debugging and maintenance phases begin; not everyone is disciplined
enough to do these two simple things, let alone stress their programs by
forcing error conditions at inopportune times and constraining resources.

I'll agree I don't care to have people seemingly arbitrarily cramp my
style, but I sure was thankful for coding standards when I inherited
someone else's code.

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

-- 
Paul Sander        (408) 734-9822       | Do YOU get nervous when a
paul at athertn.Atherton.COM               | sys{op,adm,prg,engr} says
{decwrl,sun,hplabs!hpda}!athertn!paul   | "oops..." ?