bill@twwells.uucp (T. William Wells) (01/08/89)
In article <196@mstan.Morgan.COM> dff@Morgan.COM (Daniel F. Fisher) writes: : 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); : } : Agreed, but I find this even more readable: if (p != 0 && p->barp != 0 && p->barp->type == BAR_BAZ_TYPE) { debazify(p->barp); saltpork(p); } or, if I were in an extravagant mood: if (p != 0 && p->barp != 0 && p->barp->type == BAR_BAZ_TYPE) { debazify(p->barp); saltpork(p); } or, possibly: if ( p != 0 && p->barp != 0 && p->barp->type == BAR_BAZ_TYPE) { debazify(p->barp); saltpork(p); } Note the eight column indentation for control structure. I can then use any indentation from two to six for continuation of the expression; more than enough space and flexibility to make things stand out well. Thus I don't care about the braces. Here's a hypothesis: there is a relationship between peoples' preference for brace placement and the amount of space they use for indentation. My belief is that the narrower the indentation, the greater the perceived need to make braces visible; the wider the indentation, the greater the desire to get those pesky things out of the way. So, let's have a poll: 1) The number of spaces I indent is: ___ [columns] 2) The braces are important for following the control structure or setting it off: ___ [yes/no] Anyone who would like to respond, send to me at the address below. I'll summarize the responses in a few days. --- Bill { uunet!proxftl | novavax } !twwells!bill
tainter@ihlpb.ATT.COM (Tainter) (01/11/89)
In article <305@twwells.uucp> bill@twwells.UUCP (T. William Wells) writes: >or, possibly: > > if ( p != 0 > && p->barp != 0 > && p->barp->type == BAR_BAZ_TYPE) { > debazify(p->barp); > saltpork(p); > } or better still (in my not-so-humble opinion): if (j != 0) { somefunction(); /* example WITHOUT folded expression */ } if (p != 0 && p->barp != 0 && p->barp->type == BAR_BAZ_TYPE) { debazify(p->barp); /* example WITH folded expression */ saltpork(p); } This has the advantage that your blocks stay uniformly indented. All indents are in the optimal 4-6 character range (I can point you to a report on an experiment done on this) and all indents are the same. With a reasonable editor indents are single key operations (under vi ^T,^D and autoindent do almost all your indenting) which eliminates multiple keystrokes for these with consequent better precision. The braces are moderately unobtrusive without being hard to maintain. >Bill { uunet!proxftl | novavax } !twwells!bill --johnathan.a.tainter
peter@ficc.uu.net (Peter da Silva) (01/12/89)
> if ( p != 0 > && p->barp != 0 > && p->barp->type == BAR_BAZ_TYPE) { > debazify(p->barp); > saltpork(p); > } Now me, I do this: if (p != 0 && p->barp != 0 && p->barp->type == BAR_BAZ_TYPE) { debazify(p->barp); saltpork(p); } Although up until a few months ago I preferred: if(p != 0 && p->barp != 0 && p->barp->type == BAR_BAZ_TYPE ) { debazify(p->barp); saltpork(p); } -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Work: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. `-_-' Home: bigtex!texbell!sugar!peter, peter@sugar.uu.net. 'U` Opinions may not represent the policies of FICC or the Xenix Support group.
bill@twwells.uucp (T. William Wells) (01/12/89)
Ok, the results are in. From my original message:
: Here's a hypothesis: there is a relationship between peoples'
: preference for brace placement and the amount of space they use for
: indentation. My belief is that the narrower the indentation, the
: greater the perceived need to make braces visible; the wider the
: indentation, the greater the desire to get those pesky things out of
: the way.
:
: So, let's have a poll:
:
: 1) The number of spaces I indent is: ___ [columns]
: 2) The braces are important for following
: the control structure or setting it off: ___ [yes/no]
Here is the raw data:
spaces important
3 4 no
4 4 no 1 probably 7 yes
5 1 probably
8 1 no 2 probably 2 yes
The probably's are from people who weren't explicit about their
answer but whose message suggests that they believe the braces to be
important. Marking "probably" as "yes", here is the data:
P(no) = 41%, P(yes) = 59%
spaces important
3 4 no 0 yes 100% no 0% yes
4 4 no 8 yes 33% no 66% yes
5 0 no 1 yes 0% no 100% yes
8 1 no 4 yes 20% no 80% yes
Combining the 3,4,5 lines:
spaces important
3,4,5 8 no 9 yes 47% no 53% yes
8 1 no 4 yes 20% no 80% yes
To summarize the data in English: people who use the shorter
indentations are about evenly split on the issue of the importance of
the braces. People who use a full tab stop, by and large, believe
that the braces are important. (I was the only exception.)
In other words: there may be a relationship but, if so, it is exactly
opposite from my belief.
(Glug. Glug.) One more belief down the drain. (Gurgle.)
---
Bill
{ uunet!proxftl | novavax } !twwells!billbph@buengc.BU.EDU (Blair P. Houghton) (01/13/89)
In article <2695@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >Now me, I do this: > > if (p != 0 && > p->barp != 0 && > p->barp->type == BAR_BAZ_TYPE) > { > debazify(p->barp); > saltpork(p); > } I've added a bit below that makes the syntax of the above radically different, and a red herring (maltjes, I think... :-) ): Your mission, if you decide to accept it, is to imbed this smidgen of code in the third include-file from the top and find the critical error in the ten-seconds-before-yesterday your tyrannical boss gave you to do it... if (p != 0 && p->barp != 0 && p->barp->type == BAR_BAZ_TYPE); { debazify(p->barp); saltpork(p); hungryrabbi(p); } --Blair "Hint: keep those braces as close to their related syntactic element as possible, or yer FIRED!. Well, not fired, per se, but I'll leave coding the bitmaps for you to do..."
chip@ateng.ateng.com (Chip Salzenberg) (01/17/89)
According to bph@buengc.BU.EDU (Blair P. Houghton): > "Hint: keep those braces as close > to their related syntactic element > as possible, or yer FIRED!. Well, not > fired, per se, but I'll leave coding the > bitmaps for you to do..." IMHO, this: if (condition && test) { action(); } puts about 2 inches between "if" and "{", whereas this: if (condition) { } makes the "if" and "{" adjacent. I see two dimensions when I look at a program. Apparently, not everyone does. -- Chip Salzenberg <chip@ateng.com> or <uunet!ateng!chip> A T Engineering Me? Speak for my company? Surely you jest! "It's no good. They're tapping the lines."
bph@buengc.BU.EDU (Blair P. Houghton) (01/17/89)
In article <1989Jan16.120659.18777@ateng.ateng.com> chip@ateng.ateng.com (Chip Salzenberg) writes: >According to bph@buengc.BU.EDU (Blair P. Houghton): >> "Hint: keep those braces as close >> to their related syntactic element >> as possible,[...] > > if (condition && test) { > action(); > } > >puts about 2 inches between "if" and "{", whereas this: > > if (condition) > { > } > >makes the "if" and "{" adjacent. But in making your little improvement in the elastic strain to your eye muscles, you've forgotten to accomplish the "action()"... (cheap ;-) ) It also makes your unqualified "{}" blocks hard to see. Try this: if (condition && much longer conditional expression sequence than is really excusable, with strange arrangement ef- fects) action(); { volatile gas; fprintf(stdmess,"Don't light that match!"); explode(gas); } It's not as pathological as it might seem. If you typically place your leftbrackets on the same line as the last if-statement-right- parenthesis, then this atypical example screams "lonely subblock", and such things are rare and strange enough that they should get all the help they can in being instantly and unambiguously identified. The other one is: for (boo = foo; boo < eleventeen(foo); boo +=azillion); { extern struct votalile skunkwort; static clinging socks; /* clinging is typedeffed */ int metimbers; exhortation gurgling; /* so is exhortation */ launder(socks); gag("ick!",skunkwort); shiver(metimbers); die(gurgling); } >I see two dimensions when I look at a program. Apparently, not everyone >does. In particular, your compiler doesn't. The syntax at that right-parenthesis is the important bit, and focussing on the space immediately under the "for" or "if" definitely distracts from the important bit. --Blair "I usually see as many dimensions as I have variables..."
dg@lakart.UUCP (David Goodenough) (01/19/89)
bph@buengc.BU.EDU (Blair P. Houghton) sez: > Try this: > > if (condition && much longer > conditional expression sequence > than is really excusable, with strange arrangement ef- > fects) > action(); > { > volatile gas; > > fprintf(stdmess,"Don't light that match!"); > explode(gas); > } if (condition && much longer conditional expression sequence than is really excusable, with strange arrangement effects) action(); { volatile gas; fprintf(stdmess,"Don't light that match!"); explode(gas); } Rather obvious now, isn't it. I ALWAYS place continuation lines four indent levels (i.e. 16 characters) to the right, as opposed to structure indent (one level - 4 characters) And before you complain about huge tests in conditionals, it has usually been my experience that if there _IS_ a huge test in a conditional it can be removed by a rewrite, and said rewrite generally winds up improving something else into the bargain. But then I think funny for a programmer. :-) -- dg@lakart.UUCP - David Goodenough +---+ IHS | +-+-+ ....... !harvard!xait!lakart!dg +-+-+ | AKA: dg%lakart.uucp@xait.xerox.com +---+
tony@ajfcal.UUCP (Tony Field) (01/21/89)
I cannot really understand the religious insistance on programming style in this news group. It seems to me that *poorly written code* is, by definition, poorly written. The corollary of *nicely written code* being nice immediately follows. For every hypothesis on braces, you will always find situations where the hypothesis fails. The course of action should NOT be to reject the hypothesis - but to adjust to hypothesis to allow for the new situation. For example, Chip Salzenberg uses a brace style of > > if (condition) > { > } > >makes the "if" and "{" adjacent. > This makes good sense (but not necessarily my choice). Blair Houghton's comment regarding the difficulties can be easily corrected by using Chip's suggestion of *vertical space* plus horizontal space: > if (condition && much longer ---- etc ------- > fects) > action(); > { > volatile gas; > > fprintf(stdmess,"Don't light that match!"); > explode(gas); > } now becomes: > if (condition && much longer > conditional expression sequence > than is really excusable, with strange arrangement ef- > fects) > action(); <<<<<< insert blanks for vertical separation. maybe additional indentation FOR THIS EXAMPLE is needed in the 'if' statement. > { > volatile gas; > > fprintf(stdmess,"Don't light that match!"); > explode(gas); > } also: > for (boo = foo; boo < eleventeen(foo); boo +=azillion); > { > ---- etc ----- > } becomes: > for (boo = foo; boo < eleventeen(foo); boo +=azillion) ; > { > ---- etc ----- > } I find it rather interesting that Blair DOES use vertical space to separate variable declarations from proceedural code, but DOES NOT seem to wish to use vertical space between lines of proceedural code. I have seen *excellent* code written in almost every coding style and in many different languages (even Fortran, PL/I, and Cobol). The degree of excellence is directly related to the talent of the programmer: if he/she THINKS CLEARLY, she/he will WRITE CODE CLEARLY. You cannot legislate talent or ability by use of standards. .... tony .... P.S. For the religious, I have a DOGMA that I believe in: And GOD invented white space: blessed are those who use white space with care and attention - even for APL. -- +------------------------------------ | Tony Field ..alberta!calgary!xenlink!ajfcal!tony | Calgary, Alberta, Canada
tony@ajfcal.UUCP (Tony Field) (01/21/89)
I forgot to include a second statement of DOGMA that is related to the use/obscurity of braces. Iff (and I do mean iff) a programmer is a clear thinker, then the necessary and sufficient DOGMA necessary to construct *beautiful* code is: And GOD invented white space: blessed are those who use white space with care and attention - even for APL. And GOD invented non-white space: blessed are those who use them to construct code and provide comments to illumninate the obscurity of the code. -- +------------------------------------ | Tony Field ..alberta!calgary!xenlink!ajfcal!tony | Calgary, Alberta, Canada