Re: Scheran & .hxx formatting

[Michael McClary <michael>]

> The point: the Montage group is the *customer*.  If they had trouble
> reading the code or the style, then it needs to be changed, and the
> current style is in some sense important *wrong*.  If this code won't
> normally be viewed by customers, then it is low on the priority list,
> but when we have time....

And it is because they're a "customer" that I "supported" them by
responding to Rob's inquiry.

As I understood the message to which I responded, the first problem
mentioned was that their homebrew tool didn't parse the language, not
that Rob had any difficulty reading it (though he had never encountered
such formatting, and expressed puzzlement over why anyone would do it in
such a "messy" way).

You aren't seriously suggesting that we should rehack our source code to
support customers with broken homebrew tools, are you?  I would think an
upper limit on the support for such a customer would be to identify how
his tool was broken (which Rob had already done for himself), then let
him fix it.

As to the whether the formatting was "messy": The example Rob quoted
was an abbreviation of:

	type subname(
		  type	arg1	// explanation of arg1
		, type	arg2	// explanation of arg2
		, type	arg3	// explanation of arg3
		, type	arg4	// explanation of arg4
		, type	arg5	// explanation of arg5
		, type	arg6	// explanation of arg6
		, type	arg7	// explanation of arg7
		, type	arg8	// explanation of arg8
	)

Which would not have seemed so strange if he'd seen the full form a few
times first (or if the full form had appeared in the place he was looking,
which WOULD be a reasonable head-off-the-puzzlement modification).

I'll be glad to argue at length that, if any changes should be made to
our source formatting to improve its readability by customers, all the
REST of the declarations should be changed to some variant of the above
form, rather than remaning in a form that produces such abominations as:

		type subname(type arg1, type arg2, type ar
	g3, type arg4, type arg5 /* worth commenting */, t
	ype arg6, type arg7, type arg8)

And I'm sure that some of the other programmers will be happy to take
the opposing position for the debate.  B-)  I'll be the first to admit
that my style is tuned to massive hardcopy listings, with heavy comments
and room for copious penciled notes, rather than the ultra-terse,
uncommented style that people who work only on tiny CRTs tend to develop.

I don't want to spend any more time on religious arguments about the
programming styles that we've each evolved over two decades of deep
thought, at least until the critical path contains no programmers.

(I will mention, however, that it will take a working Xanadu system and/or
 a wall of megapixel displays to eliminate the conditions that drove the
 development of the programming style I now use.  And I'm sure that most
 of the rest of us will express similar resistance to suggestions for
 midstream changes in THEIR coding styles.)

	michael