Newsgroups: comp.lang.c
Path: utzoo!henry
From: henry@utzoo.uucp (Henry Spencer)
Subject: Re: A question of style
Message-ID: <1989Nov28.184833.29328@utzoo.uucp>
Organization: U of Toronto Zoology
References: <1989Nov23.170838.10376@phri.nyu.edu> <680013@hpmwjaa.HP.COM>
Date: Tue, 28 Nov 89 18:48:33 GMT

In article <680013@hpmwjaa.HP.COM> jeffa@hpmwtd.HP.COM (Jeff Aguilera) writes:
>> I think the correct word is "wary".  My reaction would be "uh-oh -- this
>> programmer is putting his own convenience and the joys of clever coding
>> above readability and maintainability -- better treat this code as an
>> amateur production and not rely on it too much".
>
>I guess you would object to this C++ code as well:

I'm afraid so.

>I'm sure you object to
>
>    1) nonintuitive operator overloading

Depends on what is being done.  I'd certainly be very cautious about it.

>    2) proper use of comma expression

Depends on what "proper" means.  There is a difference between what a
compiler will accept and what a human can read easily.

>    3) long lines

They do cause trouble at times.

>    4) terse comments, not aligned with tabstops

Terseness I have no objection to, although messy formatting of any code
does make code harder to read.

>    5) use of = in if () statement

By and large, yes.

>    6) avoidance of newlines

Yes.  White space is not the tool of the devil, quite the contrary.

>    7) avoidance of braces

Yes.

>    8) individualistic programming styles

On the whole, yes.  Code should be intelligible to your successors, not
just to you.  This means giving up a certain amount of individuality.
Contrary to popular superstition, this does not shackle your creative
ability, it just directs it into more productive channels.  Remember the
artists' maxim:  "form liberates".

>    9) code that works so well it requires no maintenance
>       (because I have a mathematical modeling proving that
>       it works)

1. I don't care whether *you* are sure it works; what I want to know is
	whether *I* can easily assure myself it works.

2. Do you have a program that takes your source and your proof as input
	and verifies that they are consistent?  If not, then you have
	verified the correctness of your model, not your program, and
	it is important that your program be readable, so that a *human*
	can verify that it implements the model correctly.

3. What happens when the spec changes?  Then it *will* require maintenance.
-- 
That's not a joke, that's      |     Henry Spencer at U of Toronto Zoology
NASA.  -Nick Szabo             | uunet!attcan!utzoo!henry henry@zoo.toronto.edu