Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!rutgers!aramis.rutgers.edu!topaz.rutgers.edu!busboys.rutgers.edu!gaynor From: gaynor@busboys.rutgers.edu (Silver) Newsgroups: comp.lang.c Subject: Re: A question of style Message-ID: Date: 30 Nov 89 08:18:33 GMT References: <1989Nov23.170838.10376@phri.nyu.edu> <680013@hpmwjaa.HP.COM> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 69 jeffa@hpmwtd.hp.com writes: > I'm sure you object to > > 1) nonintuitive operator overloading Agreed. Strict adherence to a standardized naming scheme should be observed. > 2) proper use of comma expression Um, do you not mean "abuse of the comma expression"? The comma has its uses outside of function calls, like in conditional expressions and loop controls. > 3) long lines Here's where I disagree with the conventional idea of the cost of whitespace. Although inexpensive, whitespace is NOT free. Like all other facets of a programming language, it can be (and, in my opinion, is often) abused. The historical precedent is to generally devoting an entire line to each single relatively `atomic' programming construct. However, I feel a line should express a single idea or concept, as opposed to a single atomic programming construct. I don't see anything wrong with long lines as long as they can be read and understood without strain (often achieved with extra in-line white). In fact, I think the advantages outweigh historical precedence here. It's very convenient to be able to examine a non-trivial portion of code without constantly needing to scroll/flip pages. Gives a wholistic, you-know-where-you-stand feeling. Note that I am not advocating unindented code, one must be wary of run-on lines just like in prose, and other abuses. > 4) terse comments, not aligned with tabstops Let's just leave it at "non-aligned", ok? I'm not fond of tabs at all, and never, ever use them except where *required* (e.g., some versions of make(1)). (GNU Emacs users, consult the variable indent-tabs-mode.) > 5) use of = in if () statement I haven't fully made up my mind about this one, but I tend to agree, solely because of the (what I consider) poor choice of equality and assignment operator symbols in C. These are the words of someone who prefers <- for assignment and = for testing equality. (There's no need to start yet another war over this, is there? Good.) > 6) avoidance of newlines Agreed, tempered with 3 above. One thing I will note is that I hate to see an entire line devoted to a single damned brace - what a gawd-awful waste of visual space! Yes, I embed them; as my code is consistently block-formatted, there's no need for their emphasis. Because editors that are very smart about parenthetical constructs are readily available, I very rarely have mismatches. > 7) avoidance of braces No strong opinion either way. I use 'em as I need them, or when their absence creates visual non-uniformities (e.g., I usually either bracify both clauses of an if or neither.) > 8) individualistic programming styles Here's where I lose big-time. Non-lispers tell me they hate my C coding style. > 9) code that works so well it requires no maintenance > (because I have a mathematical modeling proving that > it works) This is in jest, right? Ok, so let the flames begin! Regards, [Ag] gaynor@topaz.rutgers.edu