roy@phri.UUCP (Roy Smith) (08/25/85)
> 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 [...] > -Michael Shannon (hplabs!oliveb!3comvax!mikes) Since I was the original poster of this particular bite, let me add a few random comments. First off, I'm really kind of amazed how much discussion this is getting. I wish people would pay this much attention when I do things correctly! Oddly enough, part of the bite was from emacs. Since the code in question was repeated several times with small changes, I wrote it once and used a macro to duplicate and modify it each time. My real goof was in defining the emacs macro. I somehow dragged the extra semi-colon along causing an error I probably wouldn't have made if I wrote each fragment by hand. Shows me to try and be clever. I put null loop-bodies on a separate line like in the following example. You all know how I write null if-bodies. :-) while (eatup() != '\n') ; If the body of the [whatever] is a single simple statement, I leave out the braces and do something like the following (I'm using "simple" in the generic sense, not strictly as defined by the C grammer): if (foo >= bar) | while (*foo++ == bar) sum += foo; | printf ("still a bar\n"); else | toosmall++; | If the body is more complicated than an assignment or function call, I put it in braces, even though they really aren't needed, thus: while ((foo = getfoo()) != EOF) | { | for (x=0; x <= 10; x++) if (foo >= bar) | { sum += foo; | for (y=0; y <= 10; y++) else | sumxy += x * y; toosmall++; | } } | The entire "if-else" or "for" construct is a single statement, but intuitively I think about lines and statements being the same (probably a holdover from my Fortran days). If I write a multi-line statement, I put braces around it to make that clear (to myself, if nobody else). Actually, in the "for" example above, I would probably drop the braces. If, however, the inner loop needed braces, the outer one would be sure to get them too. A few people have suggested I run my source through a code grinder like "cb". If the output of cb is different from its input, it's a hint I goofed somewhere. Something like "cb < foo.c | diff foo.c -" would do the job nicely. While this is a good idea, I don't see why this isn't built into "lint". OK, now can we please start working on somebody else's boo-boos? It's embarrassing to see my dirty laundry come back at me 6 times a day, even if it is somewhat amusing. -- Roy Smith <allegra!phri!roy> System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016
jrife@fthood (08/28/85)
> If the body is more complicated than an assignment or function >call, I put it in braces, even though they really aren't needed, thus: > > while ((foo = getfoo()) != EOF) | > { | for (x=0; x <= 10; x++) > if (foo >= bar) | { > sum += foo; | for (y=0; y <= 10; y++) > else | sumxy += x * y; > toosmall++; | } > } | > I like this programming style myself, Roy. But, one suggestion...if you move the braces over, you end up with the braces in line with the level of complication, and then *only* the opening and closing braces of a function are in the first column, thus: while ((foo = getfoo()) != EOF) { if (foo >= bar) sum += foo; else toosmall++; } It also makes constructs such as: while ((foo = getfoo()) != EOF) { if (foo >= bar) { sum += foo; bar = stuff * 3; } else { toosmall++; if (garbage != foo) garbage--; } } easy to understand. And, now, autoindent on vi works very nicely. -- ********************************* * * * Jeff Rife * * ihnp4!uiucuxc!fthood!jrife * * * * "Gene Simmons never had a * * personal computer when he * * was a kid." * * --Berke Breathed * * * *********************************
styborsk@hpspkla.UUCP (styborsk) (09/06/85)
This style makes a lot of sense if you look at it as follows.
The body of the if statement is ONE STATEMENT, either a single, simple
statement such as "x = 1;" or a compound statement such as
{
x = 1;
y = 2;
}
or even a null statement such as ";". In fact, the body of a while, for, etc.
falls into the same mold and everything becomes very consistent (which is very
nice if you are writing a package for an editor like Emacs to help you type
your code).
When we first tried to standardize our coding style, this looked strange to me
too, but it kind of grows on you (like a fungus :-).
Randy Styborski
{ihnp4!hpfcla!}hpspkla!styborskpreece@ccvaxa.UUCP (09/09/85)
> 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"). > /* Written 12:35 pm Sep 4, 1985 by mikes@3comvax.UUCP in > ccvaxa:net.lang.c */ ---------- Well, in my mind the braces are simply grouping the statements 'under' the if. I take the phrase "compound statement" seriously: what comes after the condition is a single entity made up of zero or more statements. Therefore I prefer to put the braces at the same indentation as the statements they bracket [actually, I prefer to leave the opening brace dangling on the same line as the condition, so that it doesn't leave an essentially empty line preceding the bracketed statements]. This style seems to ME to be closer to the ideal of having a way of grouping and distinguishing the grouped statements WITHOUT the syntactic cruft of the braces. This could be via indentation-as-syntax, font-as-syntax, or a tokenizing editor, take your pick. I see the braces as intrusive extraneous material needed because we lack proper means to express the structure of the program directly. -- scott preece gould/csd - urbana ihnp4!uiucdcs!ccvaxa!preece
jrife@fthood (09/10/85)
Sorry that this response is rather long, but here goes...
The reason I don't like:
if(condition) {
s1;
s2;
}
can be shown by the following source:
if (onelock(pid, tempfile, file) == -1) {
/* lock file exists */
/* get status to check age of the lock file */
ret = stat(file, &stbuf);
if (ret != -1) {
time(&ptime);
if ((ptime - stbuf.st_ctime) < atime) {
/* file not old enough to delete */
return(FAIL);
}
------------------------------------------------------------------------------
}
ret = unlink(file);
ret = onelock(pid, tempfile, file);
if (ret != 0)
return(FAIL);
}
stlock(file);
When I listed the file out, the page break was right where the dashed line is.
Now, I personally have a hard time figuring out which brace belongs to which,
in this case. For one thing the braces around "return(FAIL)" are unnecessary,
and this creates extra confusion, this time around.
> Why do you like this style? This seems to indicate that
>the braces are associated in your mind with the enclosed statements.
You seem to have answered your own question. What else are the braces related
to if not the enclosed statements? Note the following, which has nothing to do
with if's, while's, for's, or do's.
main()
{
int i = 42;
float foo = 3.14159;
printf("Starting program\n");
printf("i = %d, foo = %f\n",i,foo);
{ /* Truly local variables */
static char *foo = "What is the meaning of life?";
double i = 1.414;
printf("Another message\n");
printf("i = %f, foo = %s\n",i,foo);
}
/* Back to the old variables */
printf("Yet another message\n");
printf("i = %d, foo = %f\n",i,foo);
exit(0);
}
This is a program that, although useless, will compile with no problem. I
think this points out the fact that only one logical statement is allowed after
any of the control structures. The braces are required to turn more than one
physical statement into one logical statement. Note, too, that I leave the
original level of code flush with the right margin. This keeps the style
correct, and is probably the explanation that you sought as to where I picked
up this practice. I feel that the edge of the {paper,screen} does an adequate
job as a delimiter, and think the extra white space is a waste.
Secondly, my dislike for the construct that puts the braces in line with the if,
while, or whatever, is shown by the the source to uusnap. Take a look at it,
and you'll probably agree that some of those "{ statement" lines tend to get
overlooked.
--
*********************************
* *
* Jeff Rife *
* ihnp4!uiucuxc!fthood!jrife *
* *
* "Sorry about that, Chief." *
* --Maxwell Smart *
* *
*********************************peter@graffiti.UUCP (Peter da Silva) (09/11/85)
> I like this programming style myself, Roy. But, one suggestion...if you move > the braces over, you end up with the braces in line with the level of > complication, and then *only* the opening and closing braces of a function are > in the first column, thus: Careful now: what you're doing here is a matter of personal style. I put the {} at the same level as the if/while/for and find *that* much easier to understand, and autoindent works just fine (translation: what are you referring to?). Not to mention the fact that it lets me use cb(1). Speaking of cb, I have a gripe: switch(x) { case 1: ... default: } What's wrong with: switch(x) { case 1: ... default: } Much easier to see the control flow. Especially if you have 2 switches in a row.
mab@druca.UUCP (Alan Bland) (09/14/85)
> to mention the fact that it lets me use cb(1). Speaking of cb, I have a gripe: > > switch(x) { > case 1: > ... > default: > } > > What's wrong with: > > switch(x) { > case 1: > ... > default: > } > > Much easier to see the control flow. Especially if you have 2 switches in a > row. The second style is another level of indentation compared to the first. Several switch statements inside a loop or two and you're off the edge of the page or screen sooner with #2 than with #1. I don't see that they're significantly different in readability (but I usually have no trouble adapting to anybody's indentation style, as long as they remain consistent). -- Alan Bland AT&T Information Systems, Denver CO {ihnp4|allegra}!druca!mab
alexis@reed.UUCP (Alexis Dimitriadis) (09/16/85)
> > 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' > Well, in my mind the braces are simply grouping the statements 'under' > the if. The above difference of opinion has in the past been called a religious argument, with good reason. Last time it was discussed, Owen Beckley, then at uw-june, conducted a poll of the preferred brace alignment and commenting style. While it may not prove anything, it should give everybody an idea of how many people will never agree to use one's own indenting style. So, without further ado, --------------------------- Well, here are the results to my C indentation/commentation survey. As a reminder, here are the catagories that I posted. Block indentation: 1) if (a == b) { 2) if (a == b) { statement1; statement1; statement2; statement2; } } 3) if (a == b) 4) if (a == b) { { statement1; statement1; statement2; statement2; } } 5) if (a == b) 6) other, please specify { statement1; statement2; } "End" comments: a) if (a == b) b) if (a == b) { { statement1; statement1; statement2; statement2; } /* if */ } /* end if */ c) none d) other, please specify e) no vote (I added this after receiving many "no votes") If the persons "other" vote only differed from one of the given choices by the number of indention spaces, I moved it to the appropriate catagory. This would be a user setable option. Indentation Type Totals for Comment type e matching braces. 4) This one was chosen by most people that hinted that they were Pascal/ Algol/ PL/I programmers. It leaves the left margin fairly clear, is easy to line up the braces with, and puts the braces with the compound statement and not the if. 5) This one was chosen for its readability and reasons like 4. 6) These "others" were quite varied and some were very strange. ---------------------- To the above let me add a couple of comments of my own: - Note that although the K&R style is the clear winner, more than half of the respondents (fifty-six percent) use a different indenting style. - Of those, most use a style that aligns the braces with each other without eating up an extra tab (style 3 or 4). Alexis Dimitriadis -- _______________________________________________ As soon as I get a full time job, the opinions expressed above will attach themselves to my employer, who will never be rid of them again. alexis @ reed {decvax,ihnp4,ucbcad,uw-beaver}!tektronix!reed.UUCP #! rnews 772 Relay-Version: version B 2.10 5/3/83 based; site houxm.UUCP Posting-Version: version B 2.10.2 (Tek) 9/28/84 based on 9/17/84; site orca.UUCP Path: houxm!vax135!cornell!uw-beaver!tektronix!orca!davecl From: davecl@orca.UUCP (Dave Clemans) Newsgroups: net.micro.atari Subject: Re: Re: Dbl clik on ST & Last DTACK Message-ID: <1733@orca.UUCP> Date: Mon, 16-Sep-85 13:08:08 EDT Article-I.D.: orca.1733 Posted: Mon Sep 16 13:08:08 1985 Date-Received: Tue, 17-Sep-85 07:38:57 EDT References: <202@uw-june> <1741@hao.UUCP> Organization: Tektronix, Wilsonville OR Lines: 5 Double click means to press the left mouse button twice in rapid succession. The GEM desktop completely ignores the right mouse button (but user applications can of course use both mouse buttons). dgc #! rnews 1814 Relay-Version: version B 2.10 5/3/83 based; site houxm.UUCP Posting-Version: version B 2.10.2 9/5/84; site reed.UUCP Path: houxm!vax135!cornell!uw-beaver!tektronix!reed!purtell From: purtell@reed.UUCP (Lady Godiva) Newsgroups: net.singles Subject: Re: Women and Horror Film
styborsk@hpspkla.UUCP (styborsk) (09/20/85)
Yeah for D!!! (flames > /dev/null)
krl@datlog.UUCP ( Kevin Long ) (09/24/85)
> > > 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' > > > Well, in my mind the braces are simply grouping the statements 'under' > > the if. > > The above difference of opinion has in the past been called a religious > argument, with good reason. Last time it was discussed, Owen Beckley, > then at uw-june, conducted a poll of the preferred brace alignment and > commenting style. While it may not prove anything, it should give everybody > an idea of how many people will never agree to use one's own indenting style. At great risk of being Flamed to death with my clothes on here is my little gem on the subject. Curly Braces are like ears...It doesn't matter how far they stick out, it's what's between them that matters ! :-) -- /\___/\ Klong \/o o\/ The views expressed above are not those of my employer \ ^ / but those of my pet Panda UUCP: ...!mcvax!ukc!stc!datlog!krl MAIL: Data Logic Ltd., 320, Ruislip Road East, Greenford, Middlesex, UK.