Programming Style Flambe
Mark Terribile
mat at hou4b.UUCP
Mon Jan 28 11:42:47 AEST 1985
I tried to MAIL this to the author of the work in question, but the
maddog mailer at seismo couldn't make sense of what my mailer thinks
is a sensible ARPA address. (Sheesh!)
>>/*
>>martin minow @decvax.uucp mentions a programmer who uses
>>
>> label: ...
>> goto label;
>>
>>to delimit an outer loop that goes on for pages as you can easily
>>lose track of nesting levels.
>>
>>flame: anyone who does that ....
>>nice: please dont write code like that. each funxion should
>> be entirely on one page. use form feeds to separate pages.
>> thank you.
>>*/
Actually, this sounds like a pretty stiff case of omnidjikstratization to me.
OMNIDJIKSTRATIZATION: The belief that because something CAN be
done one way it always SHOULD be done that way. We CAN write
programs without returns, breaks, or continues, therefore we
should. We CAN write programs as Turing Machines, therefore we
should. We CAN write programs within the framework of Harry's
Uplifting Methodology, therefore we should.
I have found only one rule that seems to apply consistantly:
Structure the program as the problem.
This structure may be in the code, or it may be in tables, or ... .
About the only exceptions to this are the classical sorting/searching
problems. They were interesting 30 years ago because they DID NOT follow this
rule, but darn near everything seems to. If you do follow the rule, look what
you get:
1) An understanding of the problem leads to an understanding of
the program. The program is comprehendable.
2) An understanding of the program leads to an understanding of
the problem. The problem has been documented.
3) An error in the program will be reflected in a mismatch between
problem and program. Such a mismatch has a good chance of
standing out clearly. The program is debuggable.
4) A known and defined delta change in the problem requires a
well defined and well understood change in the program. The
program is maintainable -- or as I prefer to say: Malleable.
And please DON'T put the maddog form feeds in. White space
ought to communicate something just as much as code. With the proper
use of white space and the proper and consistant placement of blocks
of code and the conditions that govern them, program structure is
communicated ... but FORMFEEDS introduce spacing of random lengths
in synchronization NOT with the structure of the program but rather
in synchronization with an ARBITRARY and IRRELEVANT event -- the
passing of a fold in the paper on which the listing (if any) may be printed.
Remember: maddog spelled backwards is goddam.
from Mole End Mark Terribile
(scrape .. dig ) hou4b!mat
,.. .,, ,,, ..,***_*.
--
from Mole End Mark Terribile
(scrape .. dig ) hou4b!mat
,.. .,, ,,, ..,***_*.
More information about the Comp.lang.c
mailing list