dal (10/25/82)
Instead of lengthily discussing where to put the braces in C programs, why not have pretty-printers for different formats? Then everyone could view any syntactically correct program in a form most convenient for them. Oh, by the way, don't forget what you put IN the programs! Dan
5123mec (10/25/82)
As one who has changed my style for { and } to meet external
standards (so my wife and I could read each other's code), let
me say that it only took about ten days to become comfortable with
the new style. And having tried to maintain some terribly written
code (no indentation, multiple statements per line,....), I feel
strongly that style standards should be enforced on any project
that will involve more than one programmer over the entire life of
the product.
But there should be some kind of filter available through which
the source can be passed that will "rearrange" things to meet the
standard. This will let the diehards write things their own way,
at least initially. And I'll bet that after a few weeks maintaining
code that conforms to standards, they'll be writing conforming code
as well.
Mikeminow (10/26/82)
Actually, this note is an argument against using pretty-printers -- though one may be helpful when dealing with a total mess that someone else did. The Indian Hill style document (posted a few weeks ago to net.sources) includes the following comments on pretty-printing: "This committee recommends that programmers not rely on automatic beautifiers for the following reasons. First, the main person who benefits from good program style is the programmer himself. This is especially true in the early design of handwritten algorithms or pseudo-code. Automatic beautifiers can only be applied to complete, syntactically correct programs and hence are not available when the need for attention to white space and indentation is greatest. It is also felt that programmers can do a better job of making clear the compilete visual layout of a function or a file with the normal attention to detail of a careful programmer.... Finally, it is felt that since beatuifiers are non-trivial programs that must parse the source, the burden of maintaining it in the face of the continuing evolution of C is not worth the benefits gained by such a program." I would add to this that it is this attention to the small details of visual style that I would look for when hiring a programmer. Before I joined Dec, I worked for a company headed by an ex-stenographer. He wouldn't hire secretaries who couldn't read his dictation and v.v. Martin Minow decvax!minow
dssg (10/28/82)
More! More! I love it! (sound of hands rubbing in glee) Pointless discussions are the only ones worth having, and the hotter the better! Personally, I favour implicit blocks denoted by indentation: if (s1) dothis(); else dontdoit(); plusthis(); while (--emptybody); while (--onelinebody) theline; while (--getthepicture) one; two; Everything is neat, symmetrical, efficient, and compact; if you find it confusing you are a user and not a programmer; and best of all, no matter how much you may like the sound of "white space is at the programmer's discretion" it is what makes software obsolete, when someone cannot read your code. Every programming job I have had has involved some sort of coding standard so that co-workers could at least communicate their problems to each other. Why not make it standard? The least it will do is eliminate interminable discussions on white space style. Mark Ingram
donald (10/29/82)
Doesn't anybody think that this discussion on brace styles is just a tad silly? It seems that all articles boil down to "This is the way it OUGHT to be done for the following reasons...". It really is reminiscent of the debates about semicolons as terminators vs semicolons as separators, and about as important: there shouldn't be semicolons and there shouldn't be braces. But given that we have to have braces to group statement sequences why don't we just use any readable convention and stick to it within a given program? Don Chan, U of Toronto