Path: utzoo!mnetor!uunet!littlei!ogcvax!pase From: pase@ogcvax.UUCP (Douglas M. Pase) Newsgroups: comp.lang.prolog Subject: Re: code formatting (even more random musings) Message-ID: <1558@ogcvax.UUCP> Date: 20 Feb 88 19:56:14 GMT References: <6890@agate.BERKELEY.EDU> <630@cresswell.quintus.UUCP> <637@cresswell.quintus.UUCP> Reply-To: pase@ogcvax.UUCP (Douglas M. Pase) Organization: Oregon Graduate Center, Beaverton, OR Lines: 71 In article kam@druhi.ATT.COM (MorrisseyKA) writes: > >Uniform style is important at all scopes: within a single program, >within a project, or within a company. Differing styles, especially >within a single program, will make it more difficult for others to >understand the program. I strongly disagree with this statement. Many years back I was part of a FORTRAN 77 compiler development team. My job was to test and correct the compiler. The compiler consisted of ~100,000 lines of PL/6 code, written by 8-10 different people. One other person was supposed to do the same as me. 6 of the 10 people were top notch programmers with beautiful coding style, but the styles were completely different. The other 4 programmers varied in skill from good to beginner. When it came right down to it, picking up a routine written in one style and then switching to a different routine written in another style was no problem if both styles were good. (I had to look at everyone's code, so I had *a lot* of opportunity to do just that.) It didn't matter how radically different the two styles were. Problems arose when #1) the style was poor to begin with, or #2) it was not consistently adhered to. Poor style meant things like: too much or too little indentation, indentation schemes which were complicated, failure to use blocks on control structures (e.g. if, while) breaking lines in wierd places, heavy use of goto statements, routines or modules which were too long, excessive global variables, non-descriptive variable names, names which were similar to or easily confused with other names, sparse comments, comments which were english translations of the code they were commenting (e.g. i = i + 1; /* add 1 to i */), etc. When the style was not consistent, it was often for one of several reasons: More than one programmer had worked on the file and subsequent programmers had not been careful to retain the original style, The style was too complicated, and hence confusing even to the author, The programmer had no real concept of style, and simple indented when he "felt like it". >Even arbitrary standards are beneficial. A standard does not need to >be the best. Who can even say what best is? The value of standards is >that they are shared. Standards may be very strict to the point that they are enforced by the compiler (as in Occam), or they may be no more than general guidelines similar to the ones I have given above (but perhaps more complete and precise). I am against the more rigid end of the spectrum. But I also realize that such things may be needed where programmers are more inclined to write amorphous code. I would rather see minimum standards for readibility than have everyone's code look the same. Strict standards would require time to be spent enforcing them (standards which are not enforced are not standards) which might be more productively used elsewhere. >Karen A. Morrissey >1-303-538-4587 >ihnp4!druhi!kam -- Doug Pase -- ...ucbvax!tektronix!ogcvax!pase or pase@cse.ogc.edu (CSNet)