Xref: utzoo comp.software-eng:2551 comp.misc:7519 Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!usc!apple!netcom!hue From: hue@netcom.UUCP (Jonathan Hue) Newsgroups: comp.software-eng,comp.misc Subject: Re: Coding standards (was Re: Programmer productivity) Message-ID: <4727@netcom.UUCP> Date: 30 Nov 89 06:21:43 GMT References: <34796@regenmeister.uucp> <2226@jato.Jpl.Nasa.Gov> <128179@sun.Eng.Sun.COM> <546@sagpd1.UUCP> Reply-To: hue@netcom.UUCP (Jonathan Hue ) Distribution: na Organization: NetCom- The Bay Area's Public Access Unix System {408 997-9175 guest} Lines: 38 >In article dopey@sun.UUCP (Can't ya tell by the name) writes: >>I would set strict standards that deal with well written programs >>(e.g. IMHO a. few if any globals, b. one routine per file, c. well >>documented, etc.). (Following assumes programming in C) My $0.02: I don't agree with (b) at all. In practice, (a) and (b) are often mutually exclusive. Sometimes two or more functions will need to use the same variable, and if you can shove the functions that use it in one file and make the variable static, you save polluting your program's global name space. If you adhere to (b), you've no choice but to make it global. You can also hide functions with static that no one else is interested in. I think adhering to (b) would tempt you into writing functions longer than you really should (Aw, I don't want to come up with another filename for this 40 line chunk of code. I'll just shove it in inline wherever I need it). At my last job we had a guy that adhered to (b) because he "didn't like searching around to find out where a function was". I suggested using tags, but since he used Microsoft Word on a Mac to edit programs (then he would upload them to a Sun to compile via TOPS - I'm not kidding!) tags weren't very useful. Because of his strict adherence to (b), and his desire to keep the number of files down, he would write 700 to 2000 line functions. Regarding (c), well documented to me doesn't necessarily mean lots of comments. At one place I worked there were separate documents which described how each subsystem of the product worked. The documents gave an overview, and had separate sections for each of its parts which described what all the functions did and how they worked. The comments in the code described anything which wouldn't be obvious to someone who had read the documentation. Having this type of documentation is extremely valuable when bring new people on board. Much better than sitting down with 100K lines of code and going through it with a new hire. 'Course, none of this ever gets written until the first release goes out... -Jonathan Brought to you by Super Global Mega Corp .com