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