jeff@unh.UUCP (Jeffrey E. F. Friedl) (12/27/88)
In article <272@twwells.uucp> bill@twwells.uucp (T. William Wells) writes: > > I believe ... > that braces exist only to make the compiler happy and should > therefore be as unobtrusive as possible. Several people have said this and I disagree. I suppose that it's a matter of opinion, but to me braces are part of the C language and as such I use them extensively as cues (that's "cues", not "crutches") when reading code. It's been said that "indentation is enough to show the block structure". Sure, but taking this idea to an extreme, one could say that having all the pages in a book is sufficient to determine what page you're on -- one doesn't need page numbers. > [braces glued to a control structure are] sometimes necessary for > the compiler (but I always use the braces), but contributing little or ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^ > nothing to the understandability of the program. The indentation of ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > the program is what tells you the control relationships; the braces > are redundant information, at best they can augment what the > indentation is already telling you. If they contribute little or nothing, why put them when you don't need them (as you also said you do)? Yes, they are redundant, but going back to my (extreme) example above, page numbers in a book are redundant because you can count pages from the beginning to see where you are. It's just easier to see it right there (by the page numbers, or the braces -- both of which augment what you're already able to find determine). The only reason I say any of this is that if style is going to be discussed in a rational fashion (i.e. not a Religious FlameFest) then I think it's better to discuss braces from the point of view of "how can I use these braces to make things more readable" rather than from the point of view of "where can I stash these things". *jeff* ------------------------------------------------------------------------------ Jeffrey Eric Francis Friedl Box 2173 Babcock House ..!{uunet,decvax}!unh!jeff Durham New Hampshire 03824 I hope I'm not around Jan 18, 2038 at 10:14:08PM
john@chinet.chi.il.us (John Mundt) (12/29/88)
In article <849@unh.UUCP> jeff@unh.UUCP (Jeffrey E. F. Friedl) writes: > >In article <272@twwells.uucp> bill@twwells.uucp (T. William Wells) writes: >> >> I believe ... >> that braces exist only to make the compiler happy and should >> therefore be as unobtrusive as possible. > > Several people have said this and I disagree. I suppose >that it's a matter of opinion, but to me braces are part of >the C language and as such I use them extensively as cues I agree that braces are needed as cues and would add the following: Perhaps this has been covered in an earlier response, but braces are the only unambiguous way the compiler would have of telling indentations given that different people use different amounts of indentation. I use vi with tabstop=4, and others use tabstop=8. At times, code being moved from one machine to another gets the tabs expanded into 8 spaces. If a person takes the time to do a g/ /s//^I/g ^^^^^^^^ /* eight spaces */ all will be well, but if not, and a small piece of code is inserted, the compiler will be faced with a mix of spaces and tabs and would have a heck of a time figuring out what indentation was meant. Without the braces, there would be nothing visible to show the problem. And finally, vi allows you to use the "%" command to see if you have braces matched. With lots of code ending in ... } } } } } } or worse, the braces come in mighty handy. -- --------------------- John Mundt Teachers' Aide, Inc. P.O. Box 1666 Highland Park, IL john@chinet.chi.il.us (312) 998-5007 (Day voice) || -432-8860 (Answer Mach) && -432-5386 Modem
ddb@ns.UUCP (David Dyer-Bennet) (12/30/88)
In article <849@unh.UUCP> jeff@unh.UUCP (Jeffrey E. F. Friedl) writes [edited]: : :In article <272@twwells.uucp> bill@twwells.uucp (T. William Wells) writes: :> I believe ... :> that braces exist only to make the compiler happy and should :> therefore be as unobtrusive as possible. : : Several people have said this and I disagree. : : It's been said that "indentation is enough to show the :block structure". Sure, but taking this idea to an extreme, :one could say that having all the pages in a book is sufficient :to determine what page you're on -- one doesn't need page numbers. I think you've got this analogy backwards -- indenting is like page numbers, in that it enables you to determine "where you are" from looking at just the current page / line. Braces are like counting the pages in the book, because you have to go all the way forwards or backwards to determine where you are. :> [braces glued to a control structure are] sometimes necessary for :> the compiler (but I always use the braces), but contributing little or : ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^ :> nothing to the understandability of the program. The indentation of : ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ :> the program is what tells you the control relationships; the braces :> are redundant information, at best they can augment what the :> indentation is already telling you. : : If they contribute little or nothing, why put them when you don't :need them (as you also said you do)? I can't speak for Mr. Wells, but I'd say one might always use braces to avoid forgetting to add them when going from a simple statement to a compound statement under control of some construct. That is, not for readability per se but to avoid errors. Because, after all, the braces AREN'T redundant to the compiler. The conflict here is that the compiler reads the braces more easily (currently they don't read the indent at all), whereas most humans I've asked read the indent more easily. : The only reason I say any of this is that if style is going :to be discussed in a rational fashion (i.e. not a Religious FlameFest) :then I think it's better to discuss braces from the point of view of :"how can I use these braces to make things more readable" rather than :from the point of view of "where can I stash these things". I think the most readable use of braces is to make them inconspicuous, except for the one case of the closing brace of a block when that's the last character of a block. The non-K&R styles I've seen have the braces getting in the way of scanning the indent levels, for me. Yours for flame-free and informative discussions, -- -- David Dyer-Bennet ...!{rutgers!dayton | amdahl!ems | uunet!rosevax}!umn-cs!ns!ddb ddb@Lynx.MN.Org, ...{amdahl,hpda}!bungia!viper!ddb Fidonet 1:282/341.0, (612) 721-8967 hst/2400/1200/300
bill@twwells.uucp (T. William Wells) (01/04/89)
In article <7300@chinet.chi.il.us> john@chinet.chi.il.us (John Mundt) writes: : In article <849@unh.UUCP> jeff@unh.UUCP (Jeffrey E. F. Friedl) writes: : > : >In article <272@twwells.uucp> bill@twwells.uucp (T. William Wells) writes: : >> : >> I believe ... : >> that braces exist only to make the compiler happy and should : >> therefore be as unobtrusive as possible. : > : > Several people have said this and I disagree. I suppose : >that it's a matter of opinion, but to me braces are part of : >the C language and as such I use them extensively as cues : : I agree that braces are needed as cues and would add the following: I said that braces are *redundant* information. In other words, if you indent the code correctly, the braces don't add additional information. In fact, that is tautological: if the braces *do* add additional information, you've indented the program incorrectly. At best, they provide confirmation of what one should already know about the program. : At times, code being moved from one machine to another gets the tabs : expanded into 8 spaces. If a person takes the time to do a : : g/ /s//^I/g : ^^^^^^^^ /* eight spaces */ : : all will be well, but if not, He deserves whatever grief he gets. Actually, if one puts tabs into code, hoping that they will be interpreted as anything other than eight space tabs, one is asking for grief. It's fine for one's editor to treat an input tab as whatever number of spaces you want, but it should put *spaces* into the file, not tab characters, not unless they represent eight space tabs. Any other approach hasn't got a chance of being portable. (And if you *really* want portability, don't use tabs at all. Where I work, we compromise by allowing tab characters at the beginning of a line only, and they represent eight spaces exactly.) : and a small piece of code is inserted, : the compiler will be faced with a mix of spaces and tabs and would : have a heck of a time figuring out what indentation was meant. : Without the braces, there would be nothing visible to show the problem. However, as I said, the braces should *always* be put in. This, however, is mostly for the *writer* of the code: having the braces always there can save him from embarrassing mistakes. For the reader, the braces only contribute to a sense of uniformity; this permits the reader to more readily understand the program. : And finally, vi allows you to use the "%" command to see if you have : braces matched. The editor I use (Mined) can be made to move the cursor for a moment to the matching brace, parenthesis, or bracket; this is even better. --- Bill { uunet!proxftl | novavax } !twwells!bill
bill@twwells.uucp (T. William Wells) (01/05/89)
In article <849@unh.UUCP> jeff@unh.UUCP (Jeffrey E. F. Friedl) writes: : : In article <272@twwells.uucp> bill@twwells.uucp (T. William Wells) writes: : > I believe ... : > that braces exist only to make the compiler happy and should : > therefore be as unobtrusive as possible. : It's been said that "indentation is enough to show the : block structure". Sure, but taking this idea to an extreme, : one could say that having all the pages in a book is sufficient : to determine what page you're on -- one doesn't need page numbers. Drop using analogies. They are never proper means of demonstration. Not only that, but yours does not even succeed as an illustration. It's completely wrong, there being no relationship between the purpose of page numbers in a book and the purpose of indentation or braces in a program. The page numbers are in the book because one wants absolute information, to be used without reference to the surrounding pages; the braces or indentation are there to indicate relationships. The two are not comparable. : > [braces glued to a control structure are] sometimes necessary for : > the compiler (but I always use the braces), but contributing little or : ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^ : > nothing to the understandability of the program. The indentation of : ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ : > the program is what tells you the control relationships; the braces : > are redundant information, at best they can augment what the : > indentation is already telling you. : : If they contribute little or nothing, why put them when you don't : need them (as you also said you do)? They are there for the *writer* of the code. They help prevent mistakes. Also, closing braces provide continuity in the indentation so that determining what the indentation actually is becomes an easier perceptual task. : It's just easier to see it right there (by : the page numbers, or the braces -- both of which augment what you're : already able to find determine). But you have forgotten or don't know an important fact: to understand the code, using braces, one must *conceptually* identify the relationship between the parts. This takes time. This also takes concentration and part of one's short term memory. Indentation, on the other hand, relies on one's perceptual systems; this is automatic, takes essentially no time, and costs nothing in terms of concentration and short term memory. : The only reason I say any of this is that if style is going : to be discussed in a rational fashion (i.e. not a Religious FlameFest) : then I think it's better to discuss braces from the point of view of : "how can I use these braces to make things more readable" rather than : from the point of view of "where can I stash these things". But that is an incorrect point of view: before asking "how can I use..." one *must* ask "ought I use...". And in this case, the answer is clear: braces, given the existence of indentation, are the wrong solution and should not be used for that function. It is therefore purposeless to ask how they should be used for that function. To summarize: there are (at least) two possible ways to indicate control relationships in a program, indentation and braces. They are equivalent, in the sense that the braces can always be used to generate the proper indentation and the indentation can always be used to generate the proper braces. Thus, the choice between them is between which conveys the information most readily. Since indentation does so with little cost to the reader, but braces with a large cost, the choice is clear: use indentation to convey the information. Now, for understandability, braces have little use other than to convey this control information (the exception being that closing braces provide continuity of indentation, an argument for always using braces with multiple levels of indentation) this implies that braces should be used for their only essential function: telling the compiler what the control relationships are, and should otherwise be made as unobtrusive as possible. This, among style issues, is one of the few that is actually decidable on objective grounds. Arguing it, without reference to those objective grounds is pointless. --- Bill { uunet!proxftl | novavax } !twwells!bill
dff@Morgan.COM (Daniel F. Fisher) (01/06/89)
In article <292@ttwells.uucp> bill@twwells.uucp (T. William Wells) writes: > > To summarize: there are (at least) two possible ways to indicate > control relationships in a program, indentation and braces. They are > equivalent, in the sense that the braces can always be used to > generate the proper indentation and the indentation can always be > used to generate the proper braces. Thus, the choice between them is > between which conveys the information most readily. Since > indentation does so with little cost to the reader, but braces with a > large cost, the choice is clear: use indentation to convey the > information. Now, for understandability, braces have little use other > than to convey this control information (the exception being that > closing braces provide continuity of indentation, an argument for > always using braces with multiple levels of indentation) this implies > that braces should be used for their only essential function: telling > the compiler what the control relationships are, and should otherwise > be made as unobtrusive as possible. > I three-quarters agree with him. I am in complete agreement with him on the role and importance of indentation (though he and I probably indent different distances and with different white-space :-). I do disagree regarding the role and importance of braces. First, yes, the closing brace should be used to signal a return to a lower level of indentation. But I think that this is less for the sake of continuity and has more to do with how easy it is to spot a brace. Thus since the left margin is already being scanned for indentation clues to program structure, the left margin is the right place for the closing brace. Similarly, IMHO, the opening brace should not be stashed away, but should clearly visible in the left hand margin. This might not be true if were not for the fact that indentation is often used to help make complicated control structures more understandable. Thus, I find " if ((p != (struct foo *)(0)) && (p->barp != (struct bar *)(0)) && (p->barp->type == BAR_BAZ_TYPE)) { debazify(p->barp); saltpork(p); } " more readable than " if ((p != (struct foo *)(0)) && (p->barp != (struct bar *)(0)) && (p->barp->type == BAR_BAZ_TYPE)) { debazify(p->barp); saltpork(p); } ". ^ | And yes *ALWAYS* use braces!! unobtrusive closing period for all you ex-COBOL programmers ;-) > This, among style issues, is one of the few that is actually > decidable on objective grounds. Arguing it, without reference to > those objective grounds is pointless. > Right!!! 8^) -- ------------------------- MMM for HRE in '89 ------------------------ Daniel F. Fisher Where do mooses get their trousers pressed? dff@morgan.com Maurice sez: "NO!" ------------------------- Are you an Elector? -----------------------
ray@micomvax.UUCP (Ray Dunn) (01/11/89)
In article <292@twwells.uucp> bill@twwells.UUCP (T. William Wells) writes: > >This, among style issues, is one of the few that is actually >decidable on objective grounds. Arguing it, without reference to >those objective grounds is pointless. > Unfortunately, not quite, as it presupposes that the *style* which is required to make the rest of the argument objective, is the One True Style. Thus (devils advocating), if one thinks that if (a) {b=2; c=2;} is acceptable style, then the conclusions that braces are not required and indentation is sufficient is far from objective. Don't get me wrong, I *do* believe that the fact that compilers use braces, and humans imply structure from the indentation level is the cause of many missed bugs. A simple common example even without adding the braces factor (not to be confused with bootstraps (see below) (:-) is: if (a_flag_is_set_up); do_this_now(); where the indentation clue is "stronger" than the semi-colon clue, to (some) human eyes. I was inclined to say that to *return* to a column format type approach would be retrograde, like returning to 80 column cards and Fortran (or, God Forbid, JCL). On reflection, however, on todays editing and output devices, "significant whitespace" is probably fully acceptable. The only real problem areas are with line-wraps, which will always occur, even with the best will in the world, and a set of conventions which through necessity would have to look like a current "style wars" definition. Now wouldn't it be fun getting *that* through a standards committee! [I suddenly realize that the braces/bootstrap "joke" above is, in fact colloquial, and depends on the fact that in British English "braces" is the term used where North Americans would use "suspenders"! Ah well, a joke is never worth while if it has to be explained! (:-)] -- Ray Dunn. | UUCP: ..!philabs!micomvax!ray Philips Electronics Ltd. | TEL : (514) 744-8200 Ext: 2347 600 Dr Frederik Philips Blvd | FAX : (514) 744-6455 St Laurent. Quebec. H4M 2S9 | TLX : 05-824090
bill@twwells.uucp (T. William Wells) (01/12/89)
In article <1616@micomvax.UUCP> ray@micomvax.UUCP (Ray Dunn) writes: : In article <292@twwells.uucp> bill@twwells.UUCP (T. William Wells) writes: : > : >This, among style issues, is one of the few that is actually : >decidable on objective grounds. Arguing it, without reference to : >those objective grounds is pointless. : > : : Unfortunately, not quite, as it presupposes that the *style* which is : required to make the rest of the argument objective, is the One True Style. Right you are. Well, almost. The presumption is that control relationships should always be as self-evident as possible. And given that presumption, my assertion follows. : Thus (devils advocating), if one thinks that : : if (a) {b=2; c=2;} : : is acceptable style, then the conclusions that braces are not required and : indentation is sufficient is far from objective. Agreed. However, I try to avoid arguing things like: if one screws up in this way, one can continue screwing up by doing... : I was inclined to say that to *return* to a column format type approach : would be retrograde, like returning to 80 column cards and Fortran (or, God : Forbid, JCL). On reflection, however, on todays editing and output devices, : "significant whitespace" is probably fully acceptable. The only real : problem areas are with line-wraps, which will always occur, even with the : best will in the world, and a set of conventions which through necessity : would have to look like a current "style wars" definition. : : Now wouldn't it be fun getting *that* through a standards committee! Actually, even C has a line continuation (more-or-less) standard: the backslash at the end of a line. And the dpANS makes it standard. With a consistent use of them, the conventions would not be so much of a problem. If one used a backslash to mean line continuation, as in the way the dpANS specifies it, and had a preprocessor that inserted braces when the non-continuation lines changed indentation levels, one would not ever have to use braces. (Though there are cases where I'd like to have the braces, to do special formatting in order to bring out some characteristic of my code.) --- Bill { uunet!proxftl | novavax } !twwells!bill
ray@micomvax.UUCP (Ray Dunn) (01/18/89)
In article <323@twwells.uucp> bill@twwells.UUCP (T. William Wells) writes: > [I point out that the "indentation is sufficient" argument depends on > a style preference argument] >Agreed. However, I try to avoid arguing things like: if one screws up >in this way, one can continue screwing up by doing... Which presupposes the subjective assessment that the starting point is a screw up..... >: problem areas are with line-wraps, which will always occur... >: and a set of conventions which through necessity >: would have to look like a current "style wars" definition. > >Actually, even C has a line continuation (more-or-less) standard: the >backslash at the end of a line. And the dpANS makes it standard. Ah, but then we once again would get visual indentation clues which might overwhelm the the line continuation character..... >With a consistent use of them, the conventions would not be so much >of a problem. I'm sorry, but this still just degenerates into a style preference war. -- Ray Dunn. | UUCP: ..!philabs!micomvax!ray Philips Electronics Ltd. | TEL : (514) 744-8200 Ext: 2347 600 Dr Frederik Philips Blvd | FAX : (514) 744-6455 St Laurent. Quebec. H4M 2S9 | TLX : 05-824090
flint@gistdev.UUCP (01/24/89)
I've used a language where the indentation is part of the semantics, and I
hate it that way. Here is a food-for-thought comparison, I'll let you draw
your own conclusions. First, coded using braces:
while (condition_1) {
...
while (condition_2) {
...
if (exit_condition) break; /* indent this however you like it, it */
/* exits the while (condition_2) */
...
}
}
/* What if you use indents instead of braces? */
while (condition_1)
...
while (condition_2)
...
if (exit_condition) break; /* exit while (condition_1) loop */
...
/*
An un-indented "if" would not be part of either loop, and will mark the end
of the outer while. Indent it once (as shown) and it exits the outer
"while", marks the end of the inner while, and means that the 3rd section
of ... code is actually a new block. Indent it twice and it will exit the
inner-most while and the third set of ... code becomes part of the inner
while loop.
*/
Flint Pellett, Global Information Systems Technology, Inc.
1800 Woodfield Drive, Savoy, IL 61874 (217) 352-1165
INTERNET: flint%gistdev@uxc.cso.uiuc.edu
UUCP: {uunet,pur-ee,convex}!uiucuxc!gistdev!flint