owen@uw-june (Owen Beckley) (04/08/85)
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
1 2 3 4 5 6 |
V
a 15 0 7 4 3 0 29
b 16 5 13 7 5 0 46
Comment
Type c 88 21 44 26 1 3 183
d 13 3 8 10 3 3 40
e 8 3 4 4 0 1 20
Totals for
Indent type -> 140 32 76 51 12 7 318 <- total votes
Summary of replies:
Indentation:
1) As you can see, the results are highly in favour of the traditional
K&R style. Many people said they liked this one because it saves
screen lines. I also think that this is the only one many people
have seen, and thus it is the only one that looks right.
2) The people that chose this one usually said something about saving
lines and that the brace belongs with the statements rather than the
if.
3) This one was chosen mostly for the ease of lining up the 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.
Comments:
a) This was chosen by those who thought the "end" was redundant.
b) The people that chose this one thought that it had the most meaning.
c) This was chosen by most because they thought that "end" comments
just clutter up the code and that commenting the syntax and not the
semantics was generally worthless.
d) Most who chose the "other" catagory said that they would comment on
the meaning of the condition or the compound statement itself rather
than the syntax of the if.
e) Some people didn't have any preference, and others just don't know
how to read directions :-)
Many of the people also said that they would only use these comments when
the "}" was a long way down the program from the "{" (i.e. the next page/
screen or farther).
I would like to thank all who responded and those of you that kept your
replies short and concise.
And now for some FLAMES!
I did not appreciate those of you who sent back my entire article. Don't
you think I know what I posted? I really didn't appreciate Jim Cottrell's
reply. No, number 1 is not any more "correct" than any of the others are
"wrong." The results show that there are many people that don't think
it's the only way. Jim also states that there must be 8 spaces in a tab.
Who says there has to be a tab stop between each level of indentation. I
programmed for 4 years without using them because the machines I used
didn't like them and my professors wanted 3 spaces. Also, who says a tab
stop has to be 8 spaces; typewriters have been around a lot longer than
computer terminals, and on them you can set the stops to anything you
want.
The fire is under control now.
I don't know when I'll have the time to write/modify some mlisp functions,
but now I have a good idea what people would like. Thanks again for all of
the responses.
P.S. Sorry about the assignment operator in the condition. My goof.
-----------------------------------------------------------------------------
Gentlemen in white suits: Man of the house:
We've come for your liver. - What?
You do have a liver donors card, don't you? - Why, yes.
Well, we've come for your liver! - Aaaaaaaaaaaaaaah!
Owen Beckley |\
University of Washington Computer Science /| \
owen@{uw-june.arpa|washington.arpa} / | \
{ihnp4|decvax|cornell}!uw-beaver!uw-june!owen /__|___\
\______/
Bring Back The Cup
--
-----------------------------------------------------------------------------
Gentlemen in white suits: Man of the house:
We've come for your liver. - What?
Do you have a liver donors card? - Why, yes.
Well, we want your liver now! - Aaaaaaaaaaaaaaah!
Owen Beckley |\
University of Washington Computer Science /| \
owen@{uw-june.arpa|washington.arpa} / | \
{ihnp4|decvax|cornell}!uw-beaver!uw-june!owen /__|___\
\______/
Bring Back The Cupcottrell@NBS-VMS (04/12/85)
/* > Many of the people also said that they would only use these comments when > the "}" was a long way down the program from the "{" (i.e. the next page/ > screen or farther). This would never happen if funxions were wholly on one page and form feeds were used to keep it that way. Let's get modular. > I really didn't appreciate Jim Cottrell's > reply. No, number 1 is not any more "correct" than any of the others are > "wrong." The results show that there are many people that don't think > it's the only way. Well, looks like I'm (in)famous again... Well, my choices were preferred by a factor of two to one. I can even accept putting the brace on a separate line, but the others are JUST PLAIN STUPID! Flexibility breeds indecision. I read a quote that said "Dennis Ritchie is to be commended for shepherding C programmers down a narrow path". Amen! Do it his way. Actually, the way it SHOULD have been defined is IF a==b THEN statement statement ELSE statement statement END No stupid braces, parens, or semicolons. Enuf of the `one statement' model. This is unambiguous, clear, uses a minimum of tokens, and avoids else's matching the wrong if. The Bourne shell is coded in this manner with defines for the capitalized tokens. The preprocessor also has an explicit #endif token. > Jim also states that there must be 8 spaces in a tab. > Who says there has to be a tab stop between each level of indentation. I > programmed for 4 years without using them because the machines I used > didn't like them and my professors wanted 3 spaces. Also, who says a tab > stop has to be 8 spaces; typewriters have been around a lot longer than > computer terminals, and on them you can set the stops to anything you want. Where have you been? Tabs ARE 8 spaces. Ever since DEC (were they the first?) allowed tabs for formatting. I also programmed for 4 years at U Md. indenting my code by threes only because tabs were not available. I wised up when I entered the real world (DECland?). A terminal is not a typewriter. Some of them have hardcoded tabstops every eight spaces. Your professors would have settled for four spaces or tabs if available. In your defense, however, I note that K&R is formatted with indentations of five spaces. This is probably due to the fact that it was typeset by printers, who traditionally interpret tabs as five spaces, as do typists. Also, lotsa new ttys have settable tabs, & vi has support for declaring nonstandard tabs. Unfortunately, the tty & line printer drivers still interpret tabs as eight spaces. EMACS formats code with indentation levels of four spaces. This is useful for massively indented programs, altho one could argue against massive indentation as well. In short, tabs are eight spaces, but if we could redesign the world, I might vote for four. > P.S. Sorry about the assignment operator in the condition. My goof. Nothing wrong with assignments in conditions. It's done all the time. To sum up, whenever there is more than one way of doing things, figure out a reason why one way is superior. For example, some brain-damaged cretins still insist on numbering the bits from the left end of the word or register. This is just plain wrong. The proof is left to the student as an exercise. BTW, little endian is superior to big endian. Hey, that's just the kind of guy I am. Flames expected as usual. jim "I'd rather be despised than ignored" cottrell@nbs */
dcm@busch.UUCP (Craig Miller) (04/16/85)
[ warning: slight flame ahead... ] In <9930@brl-tgr.ARPA> cottrell (jim cottrell) writes: > This would never happen if funxions were wholly on one page and form > feeds were used to keep it that way. Let's get modular. Since when does modularity mean functions wholly on one page? Are you implying that when you get close to the end of a page, you just split your current function off into 2 functions so that they'll fit on separate pages? Yep, that's real modular, alright (sigh). Here I was under the impression that modularity had more to do with what the functions *did*, not how they looked on a printout... Guess I was wrong. > Well, my choices were preferred by a factor of two to one. I can even > accept putting the brace on a separate line, but the others are JUST > PLAIN STUPID! Flexibility breeds indecision. I read a quote that said > "Dennis Ritchie is to be commended for shepherding C programmers down > a narrow path". Amen! Do it his way. "JUST PLAIN STUPID"? Real open minded, aren't we Jim? What ever happened to programming style (as in everyone has their own...). This paragraph sounds like an argument for Fortran or (yuch) COBOL. "There is only one right way you can do it (or at least should be doing it)." Yep. Here I thought one of strengths of C was it's flexibility to differing programming styles. I personally think that when it comes to readability in a program, a big part is consistency. If the person's indentation is 2 spaces, fine. Just as long as they're consistent about it, I can read it (usually :-). But, guess I was wrong again. > Actually, the way it SHOULD have been defined is > > IF a==b THEN > statement > statement > ELSE > statement > statement > END Fine. If you like it this way, use the preprocessor. But I personally like C better than Algol (at least I think it's Algol...). Do you actually find the Bourne shell source more readable than straight C? Hmmm... Algol background, eh? > Where have you been? Tabs ARE 8 spaces. Ever since DEC (were they the I thought a tab(tm of Coke) was one of those 'hardware dependent' type of things. Just because DEC did it that way means it's right? Fine. This means VMS(tm of DEC) is the only os, right? :-) > In your defense, however, I note that K&R is formatted with indentations > of five spaces. This is probably due to the fact that it was typeset by > printers, who traditionally interpret tabs as five spaces, as do typists. Or maybe if K&R had indented with 8 spaces, some of the lines wouldn't have fit on the pages? Or maybe it's five because they did it on non-DEC hardware? :-) > nonstandard tabs. Unfortunately, the tty & line printer drivers still > interpret tabs as eight spaces. Yep. But this is probably left over from the DEC-only days... > altho one could argue against massive indentation as well. Another modularity argument? I guess lines that are too long to stay on the screen aren't part of modular code, right? Right. (heavy sigh...) > To sum up, whenever there is more than one way of doing things, figure > out a reason why one way is superior. For example, some brain-damaged What's superior to you is not always what's superior to anyone else (obviously). Again, I think it's a matter of personal preference. And again, consistency is what matters the most (to me, at least). But then again, the 'preferred' way of { and } after `if', `for', etc. isn't consistent with the { and } when declaring functions, is it? The style most consistent would seem to be: int a() { if (x) { } } right? (Just for the record, my personal preference is: if (x) { } but I'd never try to push that onto anyone. :-) Oh well. Time to do some work. Enjoy... just a lowly C programmer, Craig p.s. sorry for the length. -- Craig Miller ..!ihnp4!we53!busch!dcm The Anheuser-Busch Companies; St. Louis, Mo.
henry@utzoo.UUCP (Henry Spencer) (04/17/85)
I find it quite amusing that the two following quotes appeared in the same article (in the same paragraph, in fact): > ... Real open minded, aren't we Jim? What ever > happened to programming style (as in everyone has their own...). > ... Here I thought one of strengths of C was it's > flexibility to differing programming styles. > I personally think > that when it comes to readability in a program, a big part is > consistency... When it comes to readability in a program, consistency is indeed of great importance -- consistency with what the programmer is used to. And "programmer" doesn't mean just you, not for production software. This implies using a standard programming style, not wandering off on your own. I used to have my own idiosyncratic indenting style. Then we got involved in V7 conversion, and I spent a lot of time reading and working on other peoples' code, much of it done with K&R indenting. Naturally I used K&R indenting while doing this, because mixing indenting styles within a single program is a major sin (readability and consistency, remember). It just got to be too much trouble to keep switching back and forth, once I got used to K&R indenting. It was much simpler to be compatible with the rest of the world. And I'm sure it's saved a fair bit of hassle for other people reading and using my code; certainly I got enough complaints about my odd style back in the old days. "To be clear is professional; not to be clear is unprofessional." (Sir Ernest Gowers) -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
tainter@gumby.UUCP (04/20/85)
> I find it quite amusing that the two following quotes appeared in the > same article (in the same paragraph, in fact): > > > ... Real open minded, aren't we Jim? What ever > > happened to programming style (as in everyone has their own...). > > ... Here I thought one of strengths of C was it's > > flexibility to differing programming styles. > > > I personally think > > that when it comes to readability in a program, a big part is > > consistency... > What is humorous about this ?! These statements are not inconsistent. Do you know the difference between accuracy and precision? There are corresponding levels of meaning for consistency. To automatically interpret consistency on the accuracy level is silly. However, maintaining consistency with someone elses PRIOR work is quite a reasonable means toward consistency (on the precision level). -- johnathan a.
henry@utzoo.UUCP (Henry Spencer) (04/22/85)
> > I find it quite amusing that the two following quotes appeared in the > > same article (in the same paragraph, in fact): > > > > > ... Real open minded, aren't we Jim? What ever > > > happened to programming style (as in everyone has their own...). > > > ... Here I thought one of strengths of C was it's > > > flexibility to differing programming styles. > > > > > I personally think > > > that when it comes to readability in a program, a big part is > > > consistency... > > > > What is humorous about this ?! These statements are not inconsistent. > Do you know the difference between accuracy and precision? Yes, I do. What's amusing is that the original author hasn't noticed the ambiguity in the meaning of "consistency". Especially since a (desirable) application of the other meaning directly contradicts his first point. I didn't accuse him of being inconsistent, remember, just of producing an amusing juxtaposition. I agree that interpreting "consistency" in the precision sense -- consistency with one's previous work -- is reasonable. I also think that interpreting it in the accuracy sense -- consistency with the conventions other people are used to -- is reasonable, desirable, and a basic responsibility of anyone claiming to be a professional. I find it hard to imagine anything more unprofessional than making your code harder for other people to read, just because you happen to like it that way. (Obviously I am talking about production software, not for-author's-use-only tinkering, but remember that code sometimes slides across the boundary unofficially.) -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
dcm@busch.UUCP (Craig Miller) (04/24/85)
Henry says: > Yes, I do. What's amusing is that the original author hasn't noticed > the ambiguity in the meaning of "consistency". Especially since a > (desirable) application of the other meaning directly contradicts > his first point. I didn't accuse him of being inconsistent, remember, > just of producing an amusing juxtaposition. Apparently I didn't make it clear what I was trying to say when I was talking about 'consistency' and 'readability in a program'. What I was referring to was that I found it extremely hard to read programs where the programming style changed (indentation or otherwise) in the middle of the program. I didn't say (or at least didn't mean to say) that readability had anything to do with whether or not the style matched anyone else's style. Just as long as the same style is used throughout the program, the next person that comes along can probably figure it out. This also applies to modifying someone else's code, too. If you're modifying someone else's code, you should use their style, just to keep it consistent within that program. But this doesn't mean you have to use their style when you write your own programs... What I'm getting at is that most people can probably figure out the style used in a program when they first start reading it. Then they know what to expect for the rest of the program. > I find it hard to imagine anything more unprofessional than making > your code harder for other people to read, just because you happen > to like it that way. Like I said before, my point was that it didn't matter as much what style you used, just that you kept to it. At least then you give people an idea of what you're trying to do. But I don't believe that just because you use a different style than anyone else's, you're wrong. And that's what started this, anyway. -- Craig Miller ..!ihnp4!we53!busch!dcm The Anheuser-Busch Companies; St. Louis, Mo.
mwm@ucbtopaz.CC.Berkeley.ARPA (04/25/85)
[C blows green road runners.] In article <5521@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >I find it hard to imagine anything more unprofessional than making >your code harder for other people to read, just because you happen >to like it that way. (Obviously I am talking about production software, >not for-author's-use-only tinkering, but remember that code sometimes >slides across the boundary unofficially.) In my experience code always slides across the boundary, unless you throw it away. That takes the point out of trying to preserve a style that you find easy to read. On the other hand: Whenever I read/write code, I prefer it in a format that I find easy to read. The AI community found the solution to the problem of different code formatting styles two (or more?) decades ago: customizable pretty printers (beautifiers, if you must). You read your code into the editor, notice that the format is "ugly", and tell the editor to format it the way you like it. The next person to come along goes through the same process. For an organization, you prepare a "standard" setting for the pretty printer hooks, and the code goes into that format when you check it into *cs. Everybody is happy, as they can work on the code in their favorite format (or non-format, if that's the case), and all the organizational listing look alike. What more could you want? Therefore, I am not going to make my life more difficult by trying to change my coding style to something less readable, I'm going to live with a dual standard (and force everybody else who wishes to work on my code to do the same) until I get around to writing a customizable pretty printer. <mike
faustus@ucbcad.UUCP (04/25/85)
I guess it's time for net.lang.c.religon... Actually, one solution is to have a very good C "beautifier", that everybody can run on other people's code to make it more to their liking. It seems that what there is (cb, indent...) doesn't really do all it could -- ideally it would do a complete parse of the C code and then write it all back out, after reformatting comments, renaming variables, etc. A pretty big task... Has anybody written something like this? If not, any suggestions on what sorts of things you would like it to do? Wayne
henry@utzoo.UUCP (Henry Spencer) (04/25/85)
> What I was referring to was that I found it extremely hard to > read programs where the programming style changed (indentation > or otherwise) in the middle of the program. > ... > This also applies to modifying someone else's code, too. If > you're modifying someone else's code, you should use their style, > just to keep it consistent within that program. ... Very true. No argument there. > I didn't say (or at > least didn't mean to say) that readability had anything to do > with whether or not the style matched anyone else's style. But it does! > Just > as long as the same style is used throughout the program, the > next person that comes along can probably figure it out. > ... > What I'm getting at is that most people can probably figure out > the style used in a program when they first start reading it. Of course. Somehow. After a fair bit of head-scratching and cursing. The whole point I was making is that "he can probably figure it out" is a thoroughly unprofessional attitude. You are supposed to make *SURE* he can figure it out, by making your code as clear as possible. The idea is to maximize clarity, not to aim for a minimum level and claim that it's good enough. > Like I said before, my point was that it didn't matter as much > what style you used, just that you kept to it. At least then > you give people an idea of what you're trying to do. I agree 100% that keeping to a single style (at least within each program) is more important than the specific choice of style. But this does *not* imply that the specific choice of style is unimportant. To maximize readability, use what your reader is familiar with. > But I don't believe that just because you use a different style > than anyone else's, you're wrong. Not wrong, no. Unless you are writing programs that other people are supposed to be able to read *easily*, i.e. programs that other people will need to maintain or change. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
henry@utzoo.UUCP (Henry Spencer) (04/28/85)
> ...[customizable pretty-printers solve a lot of the style problems]... > Everybody is happy, as they can work on the code in their > favorite format (or non-format, if that's the case), and all the > organizational listing look alike. What more could you want? A customizable pretty-printer that can read minds, so it can sort out those formatting decisions that are determined by intent rather than just by syntax. To quote our locally-altered manual page for cb(1), under BUGS: A paragrapher cannot judge the programmer's intent, and hence cannot do as good a job of displaying it as the programmer can. Paragraphers should be used to deal with emergencies, not as a substitute for doing it right the first time. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
geoff@utcs.UUCP (Geoff Collyer) (04/28/85)
For those of us who like ``the One True Brace Style'' (i.e. the style used in the v7 kernel and K&R), the System V cb is a big improvement over the v7 cb. The v7 one was pretty wimpy, but the System V one when invoked as `cb -s -j' does a pretty good job of making even fairly wretched code legible. It's not as good as Mike Tilson's para pretty-printer for v6 C, alas. Para could be fed a C program containing no unnecessary whitespace and produce a fairly beautifully formatted equivalent. Para had the guts to assume that the original formatting was utterly wrong and completely reformatted the program. As an aside, one of the first programs one would want to sic `cb -s -j' on is cb.c. Why is it that the sources of so many pretty-printers (notably v7 cb, Sys V cb and I believe indent) are themselves in need of pretty-printing? I'd have more confidence in a pretty-printer if its source were attractive, just as one is suspicious of a chef who won't eat his own cooking. Incidentally, the first things I usually do with incoming code are to beautify it, delint it and *then* visually inspect and debug it. I wish that these precautions were not routinely necessary; in particular I feel that I shouldn't have to delint code that originated on UNIX(tm). -- Eighth Edition: consider it UNIX.
msb@lsuc.UUCP (Mark Brader) (04/28/85)
There've been a couple of suggestions lately like this one from mwm@ucbtopaz.UUCP (Praiser of Bob (!)): > Whenever I read/write code, I prefer it in a format that I find easy to > read. The AI community found the solution to the problem of different > code formatting styles two (or more?) decades ago: customizable pretty > printers (beautifiers, if you must). You read your code into the editor, > notice that the format is "ugly", and tell the editor to format it the > way you like it. The next person to come along goes through the same > process. The trouble with this is that prettyprinters don't know what you know. Consider these two examples: if(isdigit(c)) A(); else if(isupper(c)) B(); else if(islower(c)) C(); else D(); if (snowing) A(); else if (political) B(); else if (Saturday) C(); else D(); Of course, A(), B(), etc. stand for several lines of code in each case. The first one is a case-type construct consisting of multiple tests of the same variable. The second one, on the other hand, consists of a series of completely independent tests and bears only a superficial resemblance to the first. The second one might as well have been written: if (!snowing) if (!political) if (!Saturday) D(); else C(); else B(); else A(); ... except that this is less readable in most cases. The distinction between the two constructs is often expressed by writing them like this: if (isdigit(c)) if (snowing) A(); A(); else if (isupper(c)) else B(); if (political) else if (islower(c)) B(); C(); else else if (Saturday) D(); C(); else D(); Now show me a prettyprinter that can tell these apart. Remember, it has to be able to start from the compressed form I gave originally! Then there are things like putting comments to the right of code or above it, and whether */ /* indicates two comments or end-of-line inside a comment, and carefully aligned lines to illustrate parallel operations.... prettyprinting just doesn't do it all. Really, the only solution is to make your code look like that of the people you work with.... or start your own company and make it a trade secret. Mark Brader
mwm@ucbtopaz.CC.Berkeley.ARPA (04/29/85)
In article <5548@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >> ...[customizable pretty-printers solve a lot of the style problems]... > >A customizable pretty-printer that can read minds, so it can sort out >those formatting decisions that are determined by intent rather than >just by syntax. The LISP community has been using customizable pretty-printers for quite a while now, so I suspect that the intent vs. syntax problem is inconsequential. Of course, C may be different, but there is only one way to find out. >To quote our locally-altered manual page for cb(1), under BUGS: > > A paragrapher cannot judge the programmer's intent, and hence cannot > do as good a job of displaying it as the programmer can. > Paragraphers should be used to deal with emergencies, not as a > substitute for doing it right the first time. Correct, so I do it right and don't use the (to me, incredibly unreadable) K&R format. Now, if only I could convince most of the rest of the C world of this :-). <mike PS - readability is personal things, and you *will not* convince me that the K&R format is readable, just as I won't convince you that it isn't. On the other hand, you might convince me to use the K&R format.
henry@utzoo.UUCP (Henry Spencer) (05/01/85)
> PS - readability is personal things, and you *will not* convince me that > the K&R format is readable, just as I won't convince you that it isn't. To correct (well, to make a near-hopeless gesture at correcting...) a common misconception: the K&R format is *not* hard to read/use. It is hard to *learn*. Once you make the effort to get used to it, reading it is no problem. I speak from experience here; I thought it was hard to read too, until I was forced to read it for a substantial length of time. Then it was easy. I am not arguing that difficulty of learning isn't a defect, by the way. Just pointing out that the K&R format is being maligned for the wrong thing. I won't go so far as to say "try it, you'll like it"... but I will say "if you try it seriously, you'll find it gets a lot easier". So as to end this on a realistic note... One other vice of the K&R style is that its readability degrades seriously in the presence of violations of the style rules. Any style is more readable when it is followed consistently, of course, but K&R's readability drops especially badly when the author is even a bit sloppy. There are rather too many examples of this in Unix code... -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
jas@rtech.ARPA (Jim Shankland) (05/01/85)
Henry Spencer has concisely and eloquently summed up the case against prettyprinters: > A paragrapher cannot judge the programmer's intent, and hence cannot > do as good a job of displaying it as the programmer can. > Paragraphers should be used to deal with emergencies, not as a > substitute for doing it right the first time. But I don't buy it. In most cases, the program's syntax DOES (or should) accurately reflect the programmer's intent. In cases when it doesn't, variant formatting may hinder, rather than help, comprehension: when a program's syntactic structure is clearly and consistently reflected in a display style selected by the reader of the code, the attention of the reader can focus on the MEANING of the code: the "programmer's intent." Given the choice between seeing a piece of code displayed in a syntactically consistent way selected by me, and seeing the code displayed in a syntactically variant way selected by the original programmer, with the variants intended to give me clues about the programmer's intent, I will gladly select the former option. Let me restate my case by altering Henry's statement above to make a (specious) argument against the use of high-level languages: A compiler cannot judge the programmer's intent, and hence cannot do as good a job of generating code as the programmer can. High-level languages should be used only for emergencies, and are no substitute for the programmer's hand-coding the algorithm in the first place. Jim Shankland Relational Technnology, Inc. ucbvax!mtxinu!rtech!jas ihnp4!pegasus!rtech!jas The opinions expressed above may not be shared by my dog.
wfl@maxvax.UUCP (w linke) (05/02/85)
>I agree 100% that keeping to a single style (at least within each >program) is more important than the specific choice of style. But >this does *not* imply that the specific choice of style is unimportant. I agree also. >To maximize readability, use what your reader is familiar with. The implicit assumption here is that there are no OBJECTIVE differences in the readability of programming styles (at least, among the styles being discussed here.) If this is true, then there should be very little "head-scratching" involved with reading an alternate style. After all, code is not like natural language - no matter what the style, you ALWAYS have to think about the individual tokens you're reading in order to understand it. On the other hand, if there are objective readability differences between styles (as I believe) then the decision as to what style to use should be made on the basis of their merits, and certainly not on the basis of tradition or conformity with a group. ("Its a good idea, but nobody else does it that way...")
geoff@burl.UUCP (geoff) (05/02/85)
> I am not arguing that difficulty of learning isn't a defect, by the way. > Just pointing out that the K&R format is being maligned for the wrong > thing. I won't go so far as to say "try it, you'll like it"... but I > will say "if you try it seriously, you'll find it gets a lot easier". > > Henry Spencer @ U of Toronto Zoology > {allegra,ihnp4,linus,decvax}!utzoo!henry When I learned C four years ago, I followed the K&R format for commenting code (i.e., brace at the end of the statement) and liked it. I found it was relatively easy to use, read, etc. I changed my coding style when I went to work (Bell Labs, Denver) to indent all blocks the same way K&R does functions. I found that much easier to read and use because the opening brace is always right above the matching closing brace. I find it is easier to spot the opening brace this way when I go back over code. It does have the liability that fewer meaningful lines appear on the screen, however. I have used it now for two years and will continue to do so. The only other change to the K&R commenting style I have adopted is to place all function arguments on lines by themselves indented by two spaces. geoff sherwood burl!geoff
jss@sjuvax.UUCP (J. Shapiro) (05/04/85)
Hopefully, this will end this sillyness. It is not hard to write a formatter for C. It is especially a property of such a formatter that it will be consistent, and it seems that consistency of style is desirable. I believe that this discussion has from the start confused 'style' with 'format'. If you don't like my code, use M4 or some such to reformat it to your taste. Then your complaints about where to put braces and this, that, or the other thing just don't hold. This is a problem which has been solved many times, and I am sure many people out there could write formatters for the predominant versions of C format that people seem to use. There is something to say for sticking to the K&R format for universality, but that seems to me to be a lesser problem, and certainly not worth a raging battle. On the otyher hand, I have more difficulty with code that is truly obfuscated. Much of the UNIX code, even if formatted as K&R (which happens to be the format I learned) do it, is badly written, poorly commented, and shows a certain sickening twist in the minds of the authors. I am not an OS hacker, and on those occasions when I am obliged to look at UNIX code I am sickened by the lack of clarity of the expression of the thoughts behind the code. This, it seems to me, is the real issue of 'style.' Not formatting style, but rather style of expression.
warner@orca.UUCP (Ken Warner) (05/05/85)
[BUGS]
Below is an actual example of real C code. It's in K&R orthodox bracing
style. Is it easier to read because of it? Should I change my style of
bracing to K&R? Can we stop prattling on about this religious issue?
switch (key) {
case BACK:
fprintf(stoout,"BACK\n");
if (device->s.stroke.current_editpos > 1) {
device->s.stroke.current_editpos--;
for (device->s.stroke.editptr =
&(device->s.stroke.header),
i = 1;
device->s.stroke.editptr->next->next,
i < device->s.stroke.current_editpos;
device->s.stroke.editptr =
device->s.stroke.editptr->next,
i++ ) {
;
}
} else {
#ifdef DEBUGzben@umd5.UUCP (05/07/85)
Now, isn't this rendition of the example given earlier **MUCH** easier to
read, parse, and understand?...
switch (key) {
case BACK:
fprintf(stoout,"BACK\n");
if (device->s.stroke.current_editpos > 1)
{
device->s.stroke.current_editpos--;
for ( device->s.stroke.editptr = &(device->s.stroke.header),
i = 1;
device->s.stroke.editptr->next->next,
i < device->s.stroke.current_editpos;
device->s.stroke.editptr = device->s.stroke.editptr->next,
i++ )
{ /* NADA */ }
}
Note: Braces on new line, indented by one, with code indented by another two.
Continued statements indented to level of original statement. Perhaps
something could be done to separate the FOR clauses that end with comma from
the FOR clauses that end with semicolon. I haven't been programming C long
enough to have done enough of these complex statements to have evolved a
programming style for them.
Now, come on. K., R., et al done did something really neat in coming up with
C and Unix, but they don't walk on water nor were they a result of virgin
birth. They did an awful lot of things right, and they did a few things very
very wrong. Making tab stops every eight was very very wrong. I'm sure they
didn't waste a lot of time thinking about it, they just had a bunch of DEC
hardware around and decided to use what they had. Note if you were to
trivially modify the above to indent 1 and 3 rather than 1 and 2, every other
indent would line up with a tab stop and you could (sort of) have the best of
both worlds.
And (as long as we are sharpening axes here) if you were programming in
PASCAL you could put the sucker in a WITH DEVICE clause and get rid of all
those "device->" references. AND, it would be more efficient since the
reference would only be evaluated once, at the WITH clause (clearly compiler
optimization in C compilers would have a bearing on this).
--
Ben Cranston ...{seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben zben@umd2.ARPAchris@umcp-cs.UUCP (Chris Torek) (05/08/85)
> From: warner@orca.UUCP (Ken Warner) > Below is an actual example of real C code. It's in K&R orthodox bracing > style. > switch (key) { > case BACK: > fprintf(stoout,"BACK\n"); Why isn't this "fprintf" indented another tabstop? > if (device->s.stroke.current_editpos > 1) { > device->s.stroke.current_editpos--; > for (device->s.stroke.editptr = > &(device->s.stroke.header), > i = 1; > device->s.stroke.editptr->next->next, > i < device->s.stroke.current_editpos; > device->s.stroke.editptr = > device->s.stroke.editptr->next, > i++ ) { > ; > } > } else { I don't quite understand. Is the reference to device->s.stroke.editptr->next->next in the test part of the for loop supposed to cause a memory fault if there is no next? The value is tossed because of the comma operator. This code would probably be more readable and faster if you had back pointers. Even without them, how about using register struct /*whatever_device->s.stroke_is*/ *s; . . . switch (key) { case BACK: fprintf(stoout, "BACK\n"); s = &device->s.stroke; if (s->current_editpos > 1) { s->current_editpos--; /* s->editptr = s->editptr->prev; */ s->editptr = &s->header; for (i = 1; i < s->current_editpos; i++) s->editptr = s->editptr->next; } else { > Is it easier to read because of it? Yes. (By the way, why > 1 rather than >= 1? Can't you untype the first key? The code would appear to work for editpos==1...) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@maryland
chris@umcp-cs.UUCP (Chris Torek) (05/08/85)
> From: zben@umd5.UUCP > And (as long as we are sharpening axes here) if you were programming in > PASCAL you could put the sucker in a WITH DEVICE clause and get rid of > all those "device->" references. AND, it would be more efficient since > the reference would only be evaluated once, at the WITH clause ([...]). Sorry Ben, but (assuming "device" is in a register and you've got a register offset addressing mode---both of which are perhaps dangerous assumptions) device->foo.bar.baz is about as fast as you can get: decl 24(r9) # device->foo.bar.baz--; /* sample vax code */ ("with" in Pascal generally puts a pointer to the object into a register; "device" is already a pointer to the object.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@maryland
jon@cit-vax (Jonathan P. Leech) (05/08/85)
> Now, isn't this rendition of the example given earlier **MUCH** easier to > read, parse, and understand?... Not really. What was originally posted was NOT 'K&R orthodox bracing style', anyway. It wasn't written very well either. The following version seems much better to me: switch (key) { case BACK: fprintf(stoout,"BACK\n"); foo = &(device->s.stroke); if (foo->current_editpos > 1) { int cnt = --(foo->current_editpos); foo->editptr = &(foo->header); for (i = 1; foo->editptr->next->next, i < cnt; i++) foo->editptr = foo->editptr->next; } else { #ifdef DEBUG It's smaller, faster, and I find it far easier to read. From a religous standpoint, I find empty block bodies disgusting. I think the indenting style is not anywhere near as important as applying at little thought to the code in this case, anyway. > And (as long as we are sharpening axes here) if you were programming in > PASCAL you could put the sucker in a WITH DEVICE clause and get rid of all > those "device->" references. AND, it would be more efficient since the > reference would only be evaluated once, at the WITH clause (clearly compiler > optimization in C compilers would have a bearing on this). Big deal. That's exactly what's going on above, with the additional (to me) advantage that the structure pointer being used is explicit. I sometimes confuse variables with record members in a PASCAL WITH block. -- Jon Leech jon@cit-vax.arpa __@/
neal@denelvx.UUCP (Neal Weidenhofer) (05/09/85)
****************************************************************************** > > And (as long as we are sharpening axes here) if you were programming in > PASCAL you could put the sucker in a WITH DEVICE clause and get rid of all > those "device->" references. AND, it would be more efficient since the > reference would only be evaluated once, at the WITH clause (clearly compiler > optimization in C compilers would have a bearing on this). > -- > Ben Cranston ...{seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben zben@umd2.ARPA I realize it doesn't help with the typing, but a smart compiler shouldn't have any trouble with evaluating "device" only once (as long as it's safe). I haven't used Pascal in a while. What does it do if DEVICE changes (intentionally or otherwise) in the middle of a WITH DEVICE clause? Regards, Neal Weidenhofer "Blame it on the Rolling Denelcor, Inc. Stones" <hao|csu-cs|brl-bmd>!denelcor!neal
jack@boring.UUCP (05/10/85)
Ok, I've had about enough of this. Let me here state
Jansens Theorem: Layout style is like a signature.
By this, I mean that your style of indentation, etc. is always
completely different from someone else's, and, moreover,
tends to show minor variations between your own programs.
I think religious debates about where the { should go, or whether
you should indent 3,4 or 8 spaces are not productive at all, since
everyone is sure to stick to his own style.
Also, If I have to read some software written in someone elses
signature, I need about 5 minutes to figure out his style,
and by that time I've gotten used to it. I even pick it up (for a short
while) if I have to make some minor modifications. Big changes go
in my own style, though.
I think that *any* style, if reasonable and used more-or-less
consequently, is just as readable as any other.
--
Jack Jansen, jack@mcvax.UUCP
The shell is my oyster.jss@sjuvax.UUCP (J. Shapiro) (05/12/85)
> > And (as long as we are sharpening axes here) if you were programming in > > PASCAL you could put the sucker in a WITH DEVICE clause and get rid of all > > those "device->" references. AND, it would be more efficient since the > > reference would only be evaluated once, at the WITH clause (clearly compiler > > optimization in C compilers would have a bearing on this). > > -- > > Ben Cranston ...{seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben zben@umd2.ARPA I have yet to neet a pascal compiler which correctly handled with device do foo := foo; where device.foo foo is a fieldname of device and foo is also a local variable name. With mnemonic names this happens fairly often. I therefore NEVER use this, as I can never be sure it is doing what I want... Jon Shapiro Haverford College