Xref: utzoo comp.lang.c:14721 comp.unix.wizards:13450 Path: utzoo!attcan!uunet!lll-winken!lll-lcc!pyramid!athertn!paul From: paul@athertn.Atherton.COM (Paul Sander) Newsgroups: comp.lang.c,comp.unix.wizards Subject: Standards (was Re: indentation: enough already!) Summary: DOD-STD-2167A Message-ID: <253@athertn.Atherton.COM> Date: 14 Dec 88 02:14:10 GMT References: <3229@ingr.UUCP> Organization: Atherton Technology, Sunnyvale, CA Lines: 90 In article <3229@ingr.UUCP>, crossgl@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@athertn.Atherton.COM | sys{op,adm,prg,engr} says {decwrl,sun,hplabs!hpda}!athertn!paul | "oops..." ?