paul@athertn.Atherton.COM (Paul Sander) (12/14/88)
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..." ?
gwyn@smoke.BRL.MIL (Doug Gwyn ) (12/14/88)
In article <253@athertn.Atherton.COM> paul@athertn.Atherton.COM (Paul Sander) writes: >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. I've read quite a few DoD coding standards, data format standards, program documentation requirements, etc. They're generally pretty horrible, requiring products that I personally would consider inexcusably poor workmanship! As with most government regulations, the root problem stems from the attempt to achieve a desirable goal by micro-specifying the details, rather than requiring that the goal be met. As with all forms of micro-management, it interferes with productivity.
crossgl@ingr.com. (Gordon Cross) (12/14/88)
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
burgett@adobe.com (Michael Burgett) (12/15/88)
In article <3245@ingr.com.> crossgl@ingr.UUCP (Gordon Cross) writes: [ reference to DOD STD 2167 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) > Sorry, I just can't let this pass... 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. 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) 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?? 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 some- one else.... Sorry Gordon, but you *really* need to rethink your position on this, instead of just foaming at the mouth at the mention of coding standards that *you* feel take away from your precious creativity. For me the design is the creative part, how the code is formatted is actually in the noise.... (although I *do* admit to having a personal style that I use in the lack of project standards) #include <standard_disclaimer.h> ---------------------------------- mike burgett burgett@adobe.com "squid and read bean stew served daily...."
mche@pbhyf.PacBell.COM (Mitch Che) (12/16/88)
In article <3245@ingr.com.> crossgl@ingr.UUCP (Gordon Cross) writes: >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... Left ALONE, 50 programmers will come up with 50 different reasons why the other 49 programmers should do it THEIR way. 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. 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. -- Mitch Che Pacific Bell 415-823-2454 --------------------------------------- "So what's the bird's-eye, lowdown disclaimer, disclaimer, too on this caper? Whatever that means." uucp:{ames,bellcore,sun}!pacbell!pbhyf!mche
gwyn@smoke.BRL.MIL (Doug Gwyn ) (12/16/88)
In article <3245@ingr.com.> crossgl@ingr.UUCP (Gordon Cross) writes: >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, 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).
eichin@athena.mit.edu (Mark W. Eichin) (12/16/88)
In article <3245@ingr.com.> crossgl@ingr.UUCP (Gordon Cross) writes: >What should they care so long as it works??!!! As an end user of something reply from Doug Gwyn <gwyn@brl.arpa> <9190@smoke.BRL.MIL> >>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 Excellent case in point: the recent Internet Breakins, specifically the ``ftp bug''. A bug that **HAS** to be fixed, even though the program ``works'' -- readable source makes it easier to find and squash these problems in a situation where *real time* matters. ``ftpd'' evolved over many years, and thus a number of people have had to understand it, likewise ``sendmail'' -- the code really *has* to be clear and readable or it isn't good enough (and it probably isn't portable enough either :-( ) Mark Eichin <eichin@athena.mit.edu> SIPB Member & Project Athena ``Watchmaker''
jfh@rpp386.Dallas.TX.US (The Beach Bum) (12/16/88)
In article <3245@ingr.com.> crossgl@ingr.UUCP (Gordon Cross) writes: >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!! The purpose of coding standards is to SAVE money. The development phase is ends when the product is finished. After that, the product must be maintained. It is hoped that consistent coding standards will save money in the maintenance phase. Please read `The Mythical Man Month' if you have any more questions. -- John F. Haugh II +-Quote of the Week:------------------- VoiceNet: (214) 250-3311 Data: -6272 |"Just remember, if you swap the first InterNet: jfh@rpp386.Dallas.TX.US | and second letters of USENET you get UucpNet : <backbone>!killer!rpp386!jfh +-SUENET." -- J. F. Haugh II------
prc@maxim.ERBE.SE (Robert Claeson) (12/17/88)
In article <9166@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn ) writes: > I've read quite a few DoD coding standards, data format standards, > program documentation requirements, etc. They're generally pretty > horrible, requiring products that I personally would consider > inexcusably poor workmanship! So what style do *you* use when you write code, Doug? -- Robert Claeson, ERBE DATA AB, P.O. Box 77, S-175 22 Jarfalla, Sweden Tel: +46 758-202 50 EUnet: rclaeson@ERBE.SE uucp: uunet!erbe.se!rclaeson Fax: +46 758-197 20 Internet: rclaeson@ERBE.SE
paul@athertn.Atherton.COM (Paul Sander) (12/18/88)
In article <3245@ingr.com.>, crossgl@ingr.com. (Gordon Cross) writes: > 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??!!! Unfortunately, there have been too many times when government contracts were delivered (behind schedule and over budget) where the code did not work. The DOD saw as the best way of solving this problem a standard that carefully sketched out the software development process from requirements analysis to integration and testing. By insisting that its contractors follow the standard, the quality of the software has gone up, and the amount of money spent on purchasing and maintaining defective software has decreased. > As an end user of something > like "ksh", I couldn't care less about the style of the source code because > the program works. The point is that all too often, the program didn't work. The difference between our (say) $10,000 software and their $10,000,000 software is that their software is bigger and harder to maintain. Removing as many variables as possible can only make that job easier. > [Budget balancing omitted] > > [Discussion of maintenance problems omitted] > > [In maintaining other people's code], > 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). So have we all. Not all programmers are as disciplined as we (the Net) are. But keep in mind that entry-level programmers are usually given some sort of maintenance job, and they may not be as knowledgeable about C as we are. > The point I am trying to make here is that left alone good > programmers write good code and bad programmers write bad code. I agree. > 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... > But where will it come from? The Universities are teaching so many other things that discipline cannot be emphasized enough; and with students' deadlines, any emphasis made would be lost. The taxpayers won't spring for it. That leaves the private sector; though companies like to send selected people off to school for advanced degrees, they don't usually allocate resources for basic education. As this is no longer a C or Unix topic, I suggest moving this discussion to comp.software-eng . -- Paul Sander (408) 734-9822 | Do YOU get nervous when a paul@Atherton.COM | sys{op,adm,prg,engr} says {decwrl,sun,hplabs!hpda}!athertn!paul | "oops..." ?
cramer@optilink.UUCP (Clayton Cramer) (12/22/88)
In article <10024@rpp386.Dallas.TX.US., jfh@rpp386.Dallas.TX.US (The Beach Bum) writes: . In article <3245@ingr.com.. crossgl@ingr.UUCP (Gordon Cross) writes: . .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!! . . The purpose of coding standards is to SAVE money. The development . phase is ends when the product is finished. After that, the product . must be maintained. It is hoped that consistent coding standards will . save money in the maintenance phase. . . Please read `The Mythical Man Month' if you have any more questions. . -- Or even work on one real world project, with real world quality software engineers. -- Clayton E. Cramer {pyramid,pixar,tekbspa}!optilink!cramer (Note new path!)
gwyn@smoke.BRL.MIL (Doug Gwyn ) (12/25/88)
In article <439@maxim.ERBE.SE> prc@maxim.ERBE.SE (Robert Claeson) writes: -In article <9166@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn ) writes: -> I've read quite a few DoD coding standards, data format standards, -> program documentation requirements, etc. They're generally pretty -> horrible, requiring products that I personally would consider -> inexcusably poor workmanship! -So what style do *you* use when you write code, Doug? Whatever's appropriate for the language, etc., keeping in mind the needs of future maintainers (including myself after a few months). One thing I do NOT do is provide punched-card decks and flowcharts. (DFDs and FSA diagrams, yes, flowcharts, no).