mikes@3comvax.UUCP (Mike Shannon) (08/23/85)
With regard to:
if(condition); /* the bug is the seimcolon on this line */
statement; /* this statement was intended to be
* executed iff the condition was true
*/
--------------------
I avoid getting bitten in this way by ALWAYS using {}'s after
if, while, etc. Even when I have a null statement as the body of an
while or for, I do it this way:
for(i = 0; i < MAX; i++) {
}
Always using braces with if/else also removes ambiguity concerning
"which if an else belongs to."
-Michael Shannon (hplabs!oliveb!3comvax!mikes)mikes@3comvax.UUCP (Mike Shannon) (09/04/85)
With regard to changing
if(condition) { | if(condition)
s1; into {
s2; | s1;
} | s2;
| }
[the idea is to indent the braces so that they are in the same column as
the statements they enclose]
Why do you like this style? This seems to indicate that
the braces are associated in your mind with the enclosed statements.
In my mind, the braces are associaed with the 'if' statment, and
so they should be indented at the same column as the 'if'. I look for
the closing brace in the same column to be a sort of 'statement terminator'
(i.e. when I see it, I think "Ah, the end of the if statement").
I've seen this unusual indentation style before, and I'm curious
if you developed a preference for it in learning some other language?
For some reason, I find this style to be especially hard to read. Anybody
else feel the same way?
--
Michael Shannon {ihnp4,hplabs}!oliveb!3comvax!mikesgwyn@BRL.ARPA (VLD/VMB) (09/06/85)
The curly braces { } have NOTHING to do with the if().
Code formatting rules that pretend otherwise are misleading.
People who indent like
if ( cond )
{
stmt1
stmt2
}
most likely do so because the compound statement
{
stmt1
stmt2
}
is under control of the if(). The only slight possible quibble is
that really the insides of a compound statement could be indented
to show the scope of the compound statement:
{
stmt1
stmt2
}
With 8-column tab spacing, though, this turns out to be unworkable,
so virtually everyone using this style doesn't indent the insides
of a compound statement.adam@npois.UUCP (Adam V. Reed) (09/07/85)
Michael Shannon {ihnp4,hplabs}!oliveb!3comvax!mikes writes: > With regard to changing > > if(condition) { | if(condition) > s1; into { > s2; | s1; > } | s2; > | } > > [the idea is to indent the braces so that they are in the same column as > the statements they enclose] > > Why do you like this style? This seems to indicate that > the braces are associated in your mind with the enclosed statements. > In my mind, the braces are associaed with the 'if' statment, and > so they should be indented at the same column as the 'if'. I look for > the closing brace in the same column to be a sort of 'statement terminator' > (i.e. when I see it, I think "Ah, the end of the if statement"). > I've seen this unusual indentation style before, and I'm curious > if you developed a preference for it in learning some other language? According to K&R, Appendix A, section 9, the braces together with the declarations and statements they enclose form a single syntactic entity called "compound statement" or, equivalently, "block". This means that the braces are conceptually associated with the statements they enclose, and NOT with anything before or after. I use the form on the right exclusively, because I find it easier to keep a "block" together in my mind if it looks like, well, a single BLOCK. Except for people who have assimilated some very sloppy mental habits, programs are easier to read if visual entities correspond to syntactic and conceptual entities. I learned to align corresponding opening and closing symbols while coding in LISP, but I found the underlying psychological principle to be equally applicable to every language I encountered in the last 20 years. Adam Reed (ihnp4!npois!adam)
zben@umd5.UUCP (09/07/85)
In article <209@3comvax.UUCP> mikes@3comvax.UUCP (Mike Shannon) writes: >With regard to changing > if(condition) { | if(condition) > s1; into { > s2; | s1; > } | s2; > | } >[the idea is to indent the braces so that they are in the same column as > the statements they enclose] Actually, I prefer: if (condition) { s1; s2; } If I had to rationalize, I would say that the { and } are intermediate in level between the mainline code and the controlled statements, and that their indenting reflects this intermediate status. Also, you can draw lines on the listing between the brackets and manually verify nesting status. This seems very useful, as the C compilers I have used don't seem to be very good at giving meaningful diagnostics in this case. (Can you say "pathological"? I *knew* you could!) Also note, indent by one and then two, so each level of indenting takes only three columns. This means you can program a more complicated routine before you start running out of space on the right. You shouldn't be programming routines that are that complex? Silly person, this is C! Any language in which *(*(*(*(*(int ()(*)()(*)))))) is a legal declaration can't put much emphasis on clarity, can it? (I know, religious statement...). Guess it's a good thing my terminal doesn't do tabs, or I would be locked into that silly "every 8" standard and writing twice as many functions as I had to... -- Ben Cranston ...{seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben zben@umd2.ARPA
rlk@chinet.UUCP (Richard L. Klappal) (09/07/85)
In article <209@3comvax.UUCP> mikes@3comvax.UUCP (Mike Shannon) writes: > >With regard to changing > > if(condition) { | if(condition) > s1; into { > s2; | s1; > } | s2; > | } > >[the idea is to indent the braces so that they are in the same column as > the statements they enclose] > > Why do you like this style? This seems to indicate that >the braces are associated in your mind with the enclosed statements. > In my mind, the braces are associaed with the 'if' statment, and >so they should be indented at the same column as the 'if'. I look for >the closing brace in the same column to be a sort of 'statement terminator' >(i.e. when I see it, I think "Ah, the end of the if statement"). > I've seen this unusual indentation style before, and I'm curious >if you developed a preference for it in learning some other language? >For some reason, I find this style to be especially hard to read. Anybody >else feel the same way? >-- > Michael Shannon {ihnp4,hplabs}!oliveb!3comvax!mikes Personally, I use the second construct you illustrated only in PL/I, reason being that the list output from the compiler shows the indent level in this format, E.i.: b: if (cond) then c: do; c: stmts; c: end; b: more stmts; where the b:, c: represent the indent level. In C, the cb program outputs statements in the style of your first example, or (again my preference): if (cond) { stmts; } I generally try adapting my coding style to the debugging/style aids are available on the system/language I which I have to work. I may not agree entirely with the way those aids put things, but when I have to repair/update someone elses code, one pass thru the PrettyPrinter puts that code into my style. -- Richard Klappal UUCP: ..!ihnp4!chinet!uklpl!rlk | "Money is truthful. If a man MCIMail: rklappal | speaks of his honor, make him Compuserve: 74106,1021 | pay cash." USPS: 1 S 299 Danby Street | Villa Park IL 60181 | Lazarus Long TEL: (312) 620-4988 | (aka R. Heinlein) -------------------------------------------------------------------------
DHowell.ES@XEROX.ARPA (09/08/85)
Personally, I don't really like the {} braces of C, nor the "begin..end"
of Pascal and its relatives. This is one thing that Ada has going for
it with its "if..then..endif" style.
I like to use these definitions:
#define IF if(
#define THEN ){
#define ELSE }else{
#define ENDIF }
Then I can write
...
IF condition THEN
statement_1
ELSE
statement_2
ENDIF
...
Which I think is much cleaner than anything using braces or begin..end.
(Gee, I should write my own language)
Dan <DHowell.ES@Xerox.ARPA>
Disclaimer: I'm having a hard time finding anyone who has my opinions
besides me.dave@andromeda.UUCP (Dave Bloom) (09/09/85)
In article <735@umd5.UUCP>, zben@umd5.UUCP writes: > Actually, I prefer: > > if (condition) > { > s1; > s2; > } > > If I had to rationalize, I would say that the { and } are intermediate in > level between the mainline code and the controlled statements, and that their > indenting reflects this intermediate status. Also, you can draw lines on the > listing between the brackets and manually verify nesting status. This seems > very useful, as the C compilers I have used don't seem to be very good at > giving meaningful diagnostics in this case. I have seen programs written in this style, and find them terribly confusing to read because there are just too many levels of indentation to the eye. Also, if you are working on a bogus editor, indenting with anything other than tabs becomes a chore. I prefer: if(some condition) { A statement; Another Statement; Some Garbage; } while(another condition) { etc; etc; } This does a few things: For starters, the opening brace does not occupy a line of its own, which makes the code a lot more compact from a visual point of view. 2) The closing brace is in line with the indented code, and serves as a terminator much as a ';', 3) The closing brace really shouldn't be in line with the if, because it is PART of the if statement and should be represented as such. You should be able to read down the program and see each statement on its own indentation level without the clutter of closing braces. -- ------------------------------------------------------------------------------- allegra\ Dave Bloom harvard \ pyramid\ seismo \ pyrnj >!andromeda!dave HOME: (201) 868-1764 ut-sally >!topaz/ WORK: (201) 648-5083 sri-iu / ihnp4!packard / "You're never alone with a schizophrenic...."
oyster@uwmacc.UUCP (Vicious Oyster) (09/09/85)
In article <411@npois.UUCP> adam@npois.UUCP (Adam V. Reed) writes: > >According to K&R, Appendix A, section 9, the braces together with the >declarations and statements they enclose form a single syntactic entity >called "compound statement" or, equivalently, "block". This means that >the braces are conceptually associated with the statements they enclose, >and NOT with anything before or after. I use the form on the right >exclusively, because I find it easier to keep a "block" together in my >mind if it looks like, well, a single BLOCK. Except for people who have >assimilated some very sloppy mental habits, programs are easier to read >if visual entities correspond to syntactic and conceptual entities. What!? The compound statement to be or not to be executed depending on the value of an "if" expression has no conceptual association with that "if" clause??? Well I'll be damned! I guess I'll just leave out all the if's, and while's, and repeat's, and for's in my programs. Sloppy mental habits? Harumph! -- - joel "vo" plutchak {allegra,ihnp4,seismo}!uwvax!uwmacc!oyster Disclaimer: Most of my postings have a :-) by default.
nather@utastro.UUCP (Ed Nather) (09/10/85)
> I prefer: > > if(some condition) { > A statement; > Another Statement; > Some Garbage; > } > while(another condition) { > etc; > etc; > } > Dave Bloom That's also the style I use, except that I set the tabs every 4 spaces so several indents will still show on the page. I tried several styles (K&R, separate lines for each brace, etc) and finally settled on this one. I'm happy with it and find it very easy to follow. Gad, Dave ... I might even be able to read *your* code! -- Ed Nather Astronomy Dept, U of Texas @ Austin {allegra,ihnp4}!{noao,ut-sally}!utastro!nather nather@astro.UTEXAS.EDU
jon@cit-vax (Jonathan P. Leech) (09/10/85)
Just to change the subject a bit on these interminable `style' debates, let me pose a question on the following: Richard Klappal [..!ihnp4!chinet!uklpl!rlk] writes: > I generally try adapting my coding style to the debugging/style > aids are available on the system/language I which I have to work. > I may not agree entirely with the way those aids put things, > but when I have to repair/update someone elses code, one pass > thru the PrettyPrinter puts that code into my style. I generally agree with this attitude, but it's not always possible. Example: I have thousands of lines of poorly-formatted code I'd LOVE to run through the 4.2 BSD `indent' program. Unfortunately, this code is heavily #ifdefed to run under different OS's (several variants of Unix, VMS, and AOS/VS). Since indent has no conception of the preprocessor, it fails miserably. It won't suffice to run the code through the preprocessor and then indent it, as it will hardly be made more readable thereby (:-). I guess what I need is a pretty-printer that has a built-in preprocessor; does anyone know where to find such a beast? -- Jon Leech (jon@cit-vax.arpa) __@/
edward@ukecc.UUCP (Edward C. Bennett) (09/10/85)
In article <1370@brl-tgr.ARPA>, DHowell.ES@XEROX.ARPA writes: > Personally, I don't really like the {} braces of C, nor the "begin..end" > of Pascal and its relatives. This is one thing that Ada has going for > it with its "if..then..endif" style. > I like to use these definitions: > #define IF if( > #define THEN ){ > #define ELSE }else{ > #define ENDIF } > ... > IF condition THEN > statement_1 > ELSE > statement_2 > ENDIF > ... > Which I think is much cleaner than anything using braces or begin..end. > Dan <DHowell.ES@Xerox.ARPA> Hmmmm, I think Dan just invented FORTRAN77! (almost)
adam@npois.UUCP (Adam V. Reed) (09/11/85)
joel "vo" plutchak {allegra,ihnp4,seismo}!uwvax!uwmacc!oyster writes: >In article <411@npois.UUCP> adam@npois.UUCP (Adam V. Reed) writes: >> >>According to K&R, Appendix A, section 9, the braces together with the >>declarations and statements they enclose form a single syntactic entity >>called "compound statement" or, equivalently, "block". This means that >>the braces are conceptually associated with the statements they enclose, >>and NOT with anything before or after. I use the form on the right >>exclusively, because I find it easier to keep a "block" together in my >>mind if it looks like, well, a single BLOCK. Except for people who have >>assimilated some very sloppy mental habits, programs are easier to read >>if visual entities correspond to syntactic and conceptual entities. > > What!? The compound statement to be or not to be executed depending on >the value of an "if" expression has no conceptual association with that "if" >clause??? Well I'll be damned! I guess I'll just leave out all the if's, and >while's, and repeat's, and for's in my programs. > Sloppy mental habits? Harumph! It is the ENTIRE compound statement, and NOT the braces delimiting it, that is conceptually associated with the expression on which it depends. This dependence is optimally communicated by indenting the ENTIRE dependent statement relative to the expression on which it depends, e.g. if (condition) { declarations; statements; } Adam V. Reed (npois!adam)
reid@unitek.uucp (Reid Spencer) (09/12/85)
In article <1370@brl-tgr.ARPA> DHowell.ES@XEROX.ARPA writes: >Personally, I don't really like the {} braces of C, nor the "begin..end" >of Pascal and its relatives. This is one thing that Ada has going for >it with its "if..then..endif" style. > >I like to use these definitions: > >#define IF if( >#define THEN ){ >#define ELSE }else{ >#define ENDIF } > >Then I can write > >... >IF condition THEN > statement_1 >ELSE > statement_2 >ENDIF >... > >Which I think is much cleaner than anything using braces or begin..end. >(Gee, I should write my own language) > >Dan <DHowell.ES@Xerox.ARPA> > >Disclaimer: I'm having a hard time finding anyone who has my opinions >besides me. Hey, don't get so down on yourself. I'm in favour of what you have suggested. How about the following: #define cycle for(;;) { #define endcycle } #define then { #define otherwise } else { #define elseif } else if #define endif } #define exitwhen(exp) if (exp) break; #define exitunless(exp) if (!(exp)) break; We can then write cycle exitwhen(cond1) if (cond2) then stuff1 elseif (cond3) then stuff2 otherwise stuff3 endif endcycle
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (09/13/85)
I have a compromise proposal that should satisy everbody:
if ( cond ) {
{ { {
stmt;
} } }
}
No matter where you like your curly braces, you got `em.roy@phri.UUCP (Roy Smith) (09/13/85)
> [#defines left out] > We can then write > > cycle > exitwhen(cond1) > if (cond2) then > stuff1 > elseif (cond3) then > stuff2 > otherwise > stuff3 > endif > endcycle OK, you can write it, but do you expect us to read it? I don't understand why people feel they have to re-invent the wheel by pre-processing the the language to death. If you want to do that, go ahead but don't call it C, because it isn't any more. -- Roy Smith <allegra!phri!roy> System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016
quiroz@rochester.UUCP (Cesar Quiroz) (09/13/85)
From article <1457@brl-tgr.ARPA> (gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>)): >I have a compromise proposal that should satisy everbody: YES IT SHOULD!@#$% ABSOLUTELY GREAT!!!! > > if ( cond ) { > { { { > stmt; > } } } > } > >No matter where you like your curly braces, you got `em. Well, let's make it: if ( cond ) { { { {{ stmt; } } }} } and that should cover 99.99% of the code ever seen in the net, with the possible exception of the obfuscated contest. Now that Doug Gwyn came out with a truly workable solution, could we put this to rest for 2 months at least? Cesar ("Now, where did I leave the c-indent package?...") -- Cesar Augusto Quiroz Gonzalez Department of Computer Science {allegra|seismo}!rochester!quiroz University of Rochester or Rochester, NY 14627 quiroz@ROCHESTER
rbutterworth@watmath.UUCP (Ray Butterworth) (09/16/85)
> How about the following: > > #define cycle for(;;) { > #define endcycle } > #define then { > #define otherwise } else { > #define elseif } else if > #define endif } > #define exitwhen(exp) if (exp) break; > #define exitunless(exp) if (!(exp)) break; > > We can then write > > cycle > exitwhen(cond1) > if (cond2) then > stuff1 > elseif (cond3) then > stuff2 > otherwise > stuff3 > endif > endcycle Looks nice, but it might end up causing more problems than it solves. It has the form of an extension of the C language, but this can be misleading since the compiler doesn't really know about it. To anyone looking at the code, the "endcycle" in the last line obviously matches the "cycle" in the first. Unfor- tunately the compiler never sees these keywords, only the "{" and "}". You could just as easily have put an "endif" in place of the "endcycle" without getting any complaint from the compiler which would produce the correct code despite the mistake. What happens when you accidentaly mess up the compound if statement so that the braces don't quite match? The compiler won't complain until half way down the next page, and you won't have a clue that the "endcycle" actually matches one of the "then" keywords. And you have lost the ability to use VI's % command to tell you which "{" matches which "}". Or consider an even worse example of this type of thing which will compile and lint without error and might even execute correctly some of the time (at least enough to pass the tests before release). cycle c=getchar(); startswitch(c) default: exitwhen(++counter>LIMIT); putchar(BEEP); break; case EOF: exitwhen(ferror(stdin)); case '\n': return; case BLAT: case BLORT: etc. dosomething(); break; etc. endswitch endcycle an_error(); How obvious is it that the "exitwhen" really generates a "break" that applies to the "case" and not to the "cycle"? The use of "break" for both "case" and "for" control is a limitation built into the C language. So is the use of "}" to end the compound statements following both a "switch" and a "for". These are features that C programmers have to live with. Using #defines to make C look like "it should" doesn't solve the problem, it only hides it, making it even harder to find when it occurs. If you really want these extensions to C, then either they should be added to the compiler or a separate pre-processor should be written which knows how to match "cycle" with "endcycle" and which can issue appropriate error messages when they don't match.
patc@tekcrl.UUCP (Pat Caudill) (09/16/85)
I seem to remember that this discussion has been hashed out
and out and out several times before. In the past it was decided that
it is a matter of religion what indention style you use. There were
four styles for braces that were offered.
A. if ( condition ) {
statments ;
more statements ;
}
B. if ( condition ) {
statments ;
more statements ;
}
C. if ( condition )
{
statments ;
more statements ;
}
D. if ( condition )
{
statments ;
more statements ;
}
I'm not sure which was the least liked but at that time A. was
most popular. This time there appear to be mayn more people using
the other formats especially D. Also there is much less radical
flaming about the other formats. (I'm a D fan myself and I have had
proponets of the other styles gain access to my directorys and
either delete or cb all my source because it was "an abomination
in the sight of God."). That seems to have gone away.
Pat Caudill
Tektronix!Tekcrl!patc
Disclaimer:
Obviously not everyone at Tektronix is of the same religion as myself.peter@graffiti.UUCP (Peter da Silva) (09/17/85)
> The curly braces { } have NOTHING to do with the if(). > Code formatting rules that pretend otherwise are misleading. Who's pretending? if(...) shortstatement; if(...) longer statement...; if(...) { lots of statements } It's only line-editor hacks who are hung up on a-line-is-a-statement anyway. (dons asbestos suit for pretection from the wirthians).
putnam@steinmetz.UUCP (jefu) (09/26/85)
The great C style debate continues....
Rather than hitting each other over the head with foam rubber curly
braces and screaming "Infidel!" at each other, why not do something
more amusing...
I have been thinking about building a language formatter for a couple
years. I want, essentially, to be able to feed it a template for the
language in question and have it spit out a formatter. This means
essentially that it must learn the syntax of the language from my
template, build a 'parser' for it, and include in the parser enough
information to be able to add the formatting commands when it spits
it out. At a minimum, i would like such to be able to handle C,
Fortran (ick), Lisp and Prolog. Unhappily, I dont have quite the
parser experience, or the time, to sit down and really make this work.
(Parenthetically, C pre-processing could break this especially for
code that is broken by pre-processor #if's in the middle of statements,
but such code is already badly damaged for human readability anyway).
Then we could all stop worrying about this problem and when confronted
with code we didnt like the 'looks' of, we could run it through our
formatter, and read it in the style we want to be accustomed to.
--
O -- jefu
tell me all about -- UUCP: edison!steinmetz!putnam
Anna Livia! I want to hear all.... -- ARPA: putnam@kbsvax.decnet@GE-CRDhenry@utzoo.UUCP (Henry Spencer) (09/30/85)
[From two different authors...] > Of course if you have an indent program that produces output that is > acceptable to you, it really doesn't matter how people write their > code, does it? > I have been thinking about building a language formatter for a couple > years... > Then we could all stop worrying about this problem and when confronted > with code we didnt like the 'looks' of, we could run it through our > formatter, and read it in the style we want to be accustomed to. Don't forget to budget for the AI software you will need to do things like getting comments in the right place. Paragraphers are not a substitute for doing the job right the first time, at least not with today's paragrapher technology. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
djm@nmtvax.UUCP (10/08/85)
In article <> putnam@kbsvax.UUCP (jefu) writes: > ... >I have been thinking about building a language formatter for a couple >years. I want, essentially, to be able to feed it a template for the >language in question and have it spit out a formatter. This means >essentially that it must learn the syntax of the language from my >template, build a 'parser' for it, and include in the parser enough >information to be able to add the formatting commands when it spits >it out. > ... Does your site have Lex and Yacc? If you want to build a parser, that's the way to go, especially if you're not particularly skilled at writing such things. Your 'template', in this case, would consist of a grammer that Yacc understands (basically). It could get a little hairy writing a grammer for some languages, but that's what job security's all about :-). Dieter Muller (uucp) ucbvax ! unmvax ! -------------------------V (uucp) [ihnp4 | cmcl2] ! lanl {ARPA | UUCP} ! --> nmtvax!djm (arpa) djm.nmt@csnet-relay (csnet) djm@nmt (mental_net) Hey you! Yeah, you with the fuzzy face! P.S. I tried a mail response, but the gateway to ARPA got somewhat ill on the address specification.