A question of style

[Silver]

jeffa at 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 at topaz.rutgers.edu