fransvo@htsa (Frans van Otten) (12/13/88)
First, let me reply to Gordon Gross. What he writes comes down
to: "A programmer is most productive when he can write programs
the way he wants to, so: No Standards ! I will use MY style
throughout eternity."
That's fine if you, and nobody else, is going to debug/update/etc
your programs. But if someone else might want to take a look at
your programs, he/she will be grateful if you had considered the
item of readability.
Gordon also writes about a teacher of his, trying to enforce his
preferred style upon his students. I once had such a teacher, too.
I opposed him, too, but I used real arguments. Your dean, saying
such requirements have no bearing on a student's ability to learn
how to write good programs, is wrong. I think it is very important
that students learn to write maintainable programs. Or do you never
work with a program someone else wrote ?
Russ Nelson writes: K&R exhibits a consistent style. I agree,
because I think that's a very good thing. When I had this quarrel
with my teacher, I asked Dennis Ritchies opinion on this matter.
Answering me, he wrote:
" I like the style used in the C book and in many Unix programs because
I regard the {} as noise that is (for C) necessary; the indentation
should show the grouping. Also, I dislike unnecessary vertical space
because it makes programs too hard to see at once. Finally it is
desired to edit programs conveniently. Thus the { is on the same
line as the for because then it does not take vertical space and is
less obtrusive; the } is on a line by itself because if it were at the
end of the last line of the group it would be hard to edit (e.g. add a
line at the end of the group), even though it takes space. It is
indented the same as the for partly because then it lines up with the
for it completes, but mostly because that is my custom.
Else is placed below if because it is equally important; the two
(or more, as in else if ) branches are not all under control of the
if but are alternatives.
I must say that rational arguments are not very persuasive.
I find it hard to read styles other than my own but do not try
to persuade people except by example. I suspect your teachers
request a certain style because it makes it easier for them to
understand your programs. "
(I included this also in anwser to John Lawitzke; he writes: "K&R exhibits
a consistent style, although they never really discuss it in depth.")
Except the placing of the {} and the if-else I agree with this. The else
is *absolutely* not equally important as the if; it is only one of the
two alternatives (see my example with the switch-statement). Placing the
{} my way uses the same amount of vertical space and is more correct:
while (1) while (1){
{ first; first;
second(); second();
etc; etc;
} }
How do you like this alternative, Gerald Hawkins ?
Doug Gwyn writes:
> ... but it's wrong. Consider
> if (a > 10)
> then putchar('1');
> something();
> else putchar('2');
> somethingElse();
Sorry Doug, must I really tell you ? C programmers should know that
compound statements should *always* be surrounded by {}. When I see
something like this, I always look twice because I can't see *any*
{ or } at all.
>Steve Bourne used a lot of (more elaborate and more correct) macro
>definitions to make his C source code look more like Algol. He was
>nearly universally cursed for having done so.
I'm not trying to make C look like any other language. I'm just trying
to keep my programs readable. As Henry Spencer writes: it is *not* all
just religion.
--
Frans van Otten
Algemene Hogeschool Amsterdam
Technische en Maritieme Faculteit
fransvo@htsa.uucpgeoff@endor.harvard.edu (Geoff Clemm) (12/15/88)
In article <663@htsa.uucp> fransvo@htsa.UUCP (Frans van Otten) writes: >I asked Dennis Ritchies opinion on this matter. >Answering me, he wrote: > > " I like the style used in the C book and in many Unix programs because > I regard the {} as noise that is (for C) necessary; the indentation > should show the grouping. Also, I dislike unnecessary vertical space > because it makes programs too hard to see at once. Finally it is > desired to edit programs conveniently. [reasons why omitted] > > Else is placed below if because it is equally important; the two > (or more, as in else if ) branches are not all under control of the > if but are alternatives. > [disclaimer about personal style omitted] As is to be expected, Ritchie's comments are the most sensible thing I have seen on this issue (thanks for posting them, Frans !). To emphasize 1. {} ARE NOISE FOR THE COMPILER - humans can see in 2d, and indentation blocks give you everything that you need. 2. If you want white space, PUT IT IN ... it is absurd to blither about how you need the {}'s to enforce white space. The space is even whiter if there are no {}'s there. 3. Editing convenience is then the determining factor for how you place your {}'s - put them in a way that minimizes numbers of keystrokes and errors during creation and modification of code. >Except the placing of the {} and the if-else I agree with this. The if-else is a separate issue (where Ritchie is also correct), but if you don't agree with the {} placement, you haven't followed what he was saying. > while (1) while (1){ > { first; first; > second(); second(); > etc; etc; > } } You have sacrificed editing convenience (i.e. being able to kill the line containing "first;" without messing with brackets) in order to get bracket column matching, which as Ritchie points out, is irrelevant. If the compiler could read white space, you would just write : while (1) first; second(); etc; As it is, you need to add brackets. The only place for the open bracket is on the first line, and you have two choices for the closing bracket (other than Ritchie's choice) : while (1) { while (1) { first; first; second(); second(); etc; }/*while*/; etc; }/*while*/; Note : the brackets DO NOT LINE UP, and it DOESN'T MATTER. Brackets are for the compiler, and it doesn't care where they are. Indentation blocks are for humans, and this bracket placement emphasizes the correct 2d blocks. (Commenting all closing brackets is my personal style ... I recommend it.) Disclaimer : Like all sensible people, I agree that the important point is to use a common style - what that style happesn to be is secondary. Geoffrey Clemm geoff@harvard.harvard.edu
gwyn@smoke.BRL.MIL (Doug Gwyn ) (12/15/88)
In article <663@htsa.uucp> fransvo@htsa.UUCP (Frans van Otten) writes: -Doug Gwyn writes: -> ... but it's wrong. Consider -> if (a > 10) -> then putchar('1'); -> something(); -> else putchar('2'); -> somethingElse(); [Frans rejoinder:] -Sorry Doug, must I really tell you ? C programmers should know that -compound statements should *always* be surrounded by {}. When I see -something like this, I always look twice because I can't see *any* -{ or } at all. [More Gwyn quote:] ->Steve Bourne used a lot of (more elaborate and more correct) macro ->definitions to make his C source code look more like Algol. He was ->nearly universally cursed for having done so. Well, ExCUSE me! I thought you were trying to make "then" work the way it does in languages that have it, not just be a totally useless piece of clutter. If you want to see how to make it work right (a la Bourne), check out the last page of Chapter 2 of "C Traps and Pitfalls" by Andrew Koenig (Addison-Wesley 1989) ISBN 0-201-17928-8. That is an EXCELLENT book for anyone who uses C (except perhaps for old C gurus, who have already had to figure this all out the hard way).
wald-david@CS.YALE.EDU (david wald) (12/15/88)
In article <832@husc6.harvard.edu> geoff@harvard.harvard.edu (Geoff Clemm) writes: >To emphasize > 1. {} ARE NOISE FOR THE COMPILER - humans can see in 2d, and indentation > blocks give you everything that you need. ... > 3. Editing convenience is then the determining factor for how you place > your {}'s - put them in a way that minimizes numbers of keystrokes > and errors during creation and modification of code. > >> while (1) while (1){ >> { first; first; >> second(); second(); >> etc; etc; >> } } > >You have sacrificed editing convenience (i.e. being able to kill the line >containing "first;" without messing with brackets) in order to get bracket >column matching, which as Ritchie points out, is irrelevant. I consider the editing convenience minimal on any of the editors I use. That however is irrelevant to my style (see below). >If the compiler could read white space, you would just write : > > while (1) > first; > second(); > etc; > >As it is, you need to add brackets. The only place for the open bracket >is on the first line, and you have two choices for the closing bracket >(other than Ritchie's choice) : > > while (1) { while (1) { > first; first; > second(); second(); > etc; }/*while*/; etc; > }/*while*/; > >Note : the brackets DO NOT LINE UP, and it DOESN'T MATTER. Brackets are >for the compiler, and it doesn't care where they are. Indentation >blocks are for humans, and this bracket placement emphasizes the correct >2d blocks. Getting a bit imperious here, aren't we? "The only place?" As long as the compilers rely on the braces to determine blocks I will stick with my style: while(1) while(1) { { first; or, if things first; second(); are crowded, second(); etc; etc; } } I understand the points about editing convenience and elimination of errors. This method has none of those problems. However, with this method I no longer run the risk of missing that first { when I change from a block to a single statement or vice versa. This method also visually shows the matching braces, which I do consider helpful in reading. Yes, the indentation helps. Indentation plus well-placed braces helps more in complex structures. The only objection I've heard to this style is that there's "too much white space," and I simply don't agree that that's a problem. >Disclaimer : Like all sensible people, I agree that the important point >is to use a common style - what that style happesn to be is secondary. Of course. ============================================================================ David Wald wald-david@yale.UUCP waldave@yalevm.bitnet ============================================================================
peter@ficc.uu.net (Peter da Silva) (12/15/88)
[ Here come the flames, it's all right. (dee dee dee... dee dee dee...) ]
I disagree. I have recently been convinced that there are cases where
the one true style is necessary for readability and editing convenience:
if( unfortunate but necessary
very long conditional )
{
stuff;
}
Indents 1 tabstop for the body, indent it to line up nicely for the
conditional. The open brace on the following line provides useful
cues for the reader. Having the brace on its own line also makes it
easier on the programmer.
I'm gradually reprogramming my human biocomputer to use this style.
--
Peter da Silva `-_-' Ferranti International Controls Corporation
"Have you hugged U your wolf today?" uunet.uu.net!ficc!peter
Disclaimer: I accept full responsibility for my typos. peter@ficc.uu.netdesnoyer@Apple.COM (Peter Desnoyers) (12/16/88)
My preference is :
if (<expr>)
{
...statement
...
}
(plus various other things) I only feel strongly about a few
indentation issues:
(1) except in very special cases 'if (<expr>) statement' should take
2 lines. Same goes for single-statement cases in a switch.
(2) Gnuemacs can't find the beginning or end of a function unless the
first and last braces are flush with the beginning of the line.
Like everyone else said, having an indentation standard is more
important than what the standard says. However, when you get into the
topic of function and module headers, you will probably find more of a
religious war, as everyone feels that their way is the one of truth,
rather than just a bit more valid than everyone else's.
These standards are crucial - you can't run code through a
pretty-printer and get comments out. My feeling is that they should
be flexible - decide on a list of things which can be described about
functions, data structures, modules, etc. (e.g. function arguments,
return value, side effects, global dependencies, references,
description.) Then only require those elements relevant to a
particular function be put in that function's header.
That approach is close to what I find myself doing. It also avoids the
trap mentioned in a previous discussion of coding standards - someone
worked at a place where the mandatory function headers were so long
that people combined functions to avoid writing headers.
Peter Desnoyersswarbric@tramp.Colorado.EDU (Frank Swarbrick) (12/16/88)
While we're on the subject, how about switch statements? This is how I do
them:
switch(c)
{
case 'a':
statement1;
statement2;
break;
/* more cases, etc... */
}
I do it this way even if I only have one statement. I used to do it this way:
switch(c)
{
case 'a':statement1;
statement2;
break;
/* etc... */
}
But that shifted everything too far to the right, and I couldn't always get
the second statement exact by just using the tab key. (ie, I had to do a few
tabs and then press space once or twice.) (Note that I use a tab of three
spaces.)
Frank Swarbrick (and, yes, the net.cat) University Of Colorado, Boulder
swarbric@tramp.Colorado.EDU ...!{ncar|nbires}!boulder!tramp!swarbric
"Loneliness: a constant friend and lover I know well" --Asiarbutterworth@watmath.waterloo.edu (Ray Butterworth) (12/16/88)
In article <832@husc6.harvard.edu>, geoff@endor.harvard.edu (Geoff Clemm) writes: > while (1) { while (1) { > first; first; > second(); second(); > etc; }/*while*/; etc; > }/*while*/; Another aspect of "Standard Indentation etc." is "where are the tabs set"? Thew above is how your example appeared to me. You obviously made an incorrect assumption that my tabs were set to something other than every 4. Either that, or you have a strange idea of how things should be formatted :-)
dhesi@bsu-cs.UUCP (Rahul Dhesi) (12/16/88)
In article <5358@boulder.Colorado.EDU> swarbric@tramp.Colorado.EDU (Frank Swarbrick) writes: >While we're on the subject, how about switch statements? Over-indentation eats up precious space. Try this: switch (expression) { case 'a': /* lots of space here for a comment */ statement ... break; case 'b': statement ... break; } /* switch */ Having each 'case' keyword aligned with the initial 'switch' keyword is similar to having 'else' aligned with 'if'. We create a comb, and pack the C code in the gaps. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi
ok@quintus.uucp (Richard A. O'Keefe) (12/16/88)
In article <2450@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: ... >Indents 1 tabstop for the body ... >I'm gradually reprogramming my human biocomputer to use this style. Where'd you get the hardware upgrade for the eyes? 8 columns is _way_ too big for an indentation increment. The range recommended by everyone except C let's-torture-test-the-eyes hackers is two to five columns for an indentation increment.
mat@mole-end.UUCP (Mark A Terribile) (12/16/88)
> Except the placing of the {} and the if-else I agree with this. The else > is *absolutely* not equally important as the if; it is only one of the > two alternatives (see my example with the switch-statement). Placing the > {} my way uses the same amount of vertical space and is more correct: > > while (1) while (1){ > { first; first; > second(); second(); > etc; etc; > } } > > How do you like this alternative, Gerald Hawkins ? It's a disaster. You can't do line manipulation, (either with a line editor (horrors) or editing by moving lines) without having to worry about your braces. My own preference is the ``brace-over-brace'' convention, but the most important thing in my mind is the consistent and *simple* arrangement of indentation. I see only two justifications for fractional-tab indents: In the switch(), it seems to help to put two spaces before each case. In a few large functions that are deeply nested, putting the last four or five indents at 4 spaces instead of a natural tab can help. The second case should be a fourth resort. The first resort is to get a clearer picture of the problem so that you can code it with fewer indents; the second is to arrange your solution in the most linear way possible (a vine rather than a bushy tree--see Kernighan & Plauger for details) using early exits where appropriate, and the third is to find a simple way to break the routine up. When those fail, go *consistently* to fractional indents for the *last few* levels ONLY. -- (This man's opinions are his own.) From mole-end Mark Terribile
mat@mole-end.UUCP (Mark A Terribile) (12/16/88)
> 1. {} ARE NOISE FOR THE COMPILER ... > blocks give you everything that you need. > 2. it is absurd [to think that] you need the {}'s to enforce white space... > 3. Editing convenience is then the determining factor ... .... > As it is, you need to add brackets. The only place for the open bracket > is on the first line, and you have two choices for the closing bracket > (other than Ritchie's choice) : > > while (1) { while (1) { > first; first; > second(); second(); > etc; }/*while*/; etc; > }/*while*/; Only if you assume that you can't afford to ``waste'' a line. If you want the most editing convenience, put the braces on lines by themselves altogether. Then when you go from a 4-statement body to a 1-statement body, you can dispense with them w/out editing the ``control'' line. > Note : the brackets DO NOT LINE UP, and it DOESN'T MATTER. Brackets are > for the compiler, and it doesn't care where they are. Indentation > blocks are for humans, and this bracket placement emphasizes the correct > 2d blocks. It matters to me because I have to get them right. For that reason, I want to keep them where I can see them. > (Commenting all closing brackets is my personal style ... I recommend it.) I *STRONGLY* disagree. If a comment parrots the code, it's useless. If it parrots the code because it's hard to see what the code is doing, it can easily get broken when the code is edited. If you indent consistently and you ``waste'' space to put nice big blank areas between the units in which you write your code, the comment-on-the-close-brace is superfluous. Indeed, if you *really* value that blank space, you don't want any needless clutter in it. You can recognize what's happening by looking at the big shapes on the page far faster than you can by reading comments hung off the ends of brace lines. > Disclaimer : Like all sensible people, I agree that the important point > is to use a common style - what that style happesn to be is secondary. Like all sensible people, I will agree so long is it is does not violate my personal *must not*s !! -- (This man's opinions are his own.) From mole-end Mark Terribile
swarbric@tramp.Colorado.EDU (Frank Swarbrick) (12/17/88)
In article <5181@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >Over-indentation eats up precious space. Try this: > > switch (expression) { > case 'a': /* lots of space here for a comment */ > statement > ... > break; > case 'b': > statement > ... > break; > } /* switch */ > >Having each 'case' keyword aligned with the initial 'switch' keyword is >similar to having 'else' aligned with 'if'. We create a comb, and pack >the C code in the gaps. My problem with that is I would have it like: switch(expression) { case 'a': statement; break; /*etc*/ } Which seems to me to be akin to doing this: if(expression) { statement1; statement2; } I know it's not quite the same, and I may even do it... (or maybe not...) Frank Swarbrick (and, yes, the net.cat) University Of Colorado, Boulder swarbric@tramp.Colorado.EDU ...!{ncar|nbires}!boulder!tramp!swarbric "Loneliness: a constant friend and lover I know well" --Asia
peter@ficc.uu.net (Peter da Silva) (12/17/88)
In article <879@quintus.UUCP>, ok@quintus.uucp (Richard A. O'Keefe) writes: > In article <2450@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: > >Indents 1 tabstop for the body > >I'm gradually reprogramming my human biocomputer to use this style. > Where'd you get the hardware upgrade for the eyes? Kodak-Fujitsu GMBH. They're second-hand... got a good deal for them from a would-be Simstim star. > 8 columns is _way_ too big for an indentation increment. Who said 8 columns? I said a tabstop. That can be anything you want. That way I can read it in 8 columns (yes, I admit it), and you can read it in 4. I like printouts with 8-column indents, but I edit in anything down to 1. -- 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.
logan@vsedev.VSE.COM (James Logan III) (12/17/88)
In article <5181@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: # Over-indentation eats up precious space. Try this: # # switch (expression) { # case 'a': /* lots of space here for a comment */ # statement # ... # break; # case 'b': # statement # ... # break; # } /* switch */ # # Having each 'case' keyword aligned with the initial 'switch' keyword is # similar to having 'else' aligned with 'if'. We create a comb, and pack # the C code in the gaps. I agree. I used to indent like this: switch (exp) { case 'a': stmt; stmt; break case 'b': stmt; stmt; break; } Until I ran into problems when building finite-state machines that required nested switch statements. Once I stopped indenting the "case" keywords I realized that I liked the way it looks better too. I see some alternate forms of indentation as inconsistent with the way braces are used in function declarations. An example follows: func() { for (;;) { stmt; stmt; } } I would probably use braces beneath and at the same level as the "for", but when I learned C many years ago I got used to the K&R style and have used it ever since. I do format long printf() statements strangely, but I think it makes sense and is consistent with the usage of braces in C. This fprintf() doesn't have a particularly long string, but it exemplifies my meaning: if ((infd = fopen(filename, "w")) == (FILE *)NULL) { fprintf( stderr, "%s: cannot open ", myname ); perror(filename); exit(1); } -- Jim Logan logan@vsedev.vse.com (703) 892-0002 uucp: ..!uunet!vsedev!logan inet: logan%vsedev.vse.com@uunet.uu.net
mec@outcast.ardent.com (Michael Chastain) (12/17/88)
OK, here's my favorite switch statement:
switch ( iThing )
{
default:
stmt;
stmt;
break;
case 1:
stmt;
stmt;
goto LCase2;
case 2:
LCase2:
stmt;
stmt;
break;
}
1. Mandatory default case
This is often an error condition. If you claim "it can never happen",
stick in a call to perror() or printf( "Unexpected default: %s %d",
__FILE__, __LINE__ ). If you still claim "it can never happen",
put in system( "rm -rf $HOME" ). Now how sure are you of your claim?
:-)
2. Default case at top
I find this easier to read. (Of course, it doesn't work in shell scripts).
3. "Case" lines up with "switch".
Why not? I was skeptical too, when I first saw it. But it's like
"else" lining up with "if". Saves a level of indentation, too.
Makes it easier to convert between "if" and "switch".
4. Failsafe "fall through".
This is how I indicate "case 1" falls through to "case 2". It
satisfies lint, and most compilers can optimize out "jump to next
statement". The big advantage is: if I move case 1 or case 2 around,
or insert "case 1.5" between them, the code still works! Gives me
one less thing to worry about when I'm rearranging my code.
/* FALL THROUGH */ is position-dependent, and "goto LCase2" is not,
and I think that's worth a goto and a label.
I agree that any style is better than no style. As T. Williams Wells
pointed out, a consistent style allows the reader to download part
of the reading task into subconscious processing.
Michael Chastain mec@ardent.com "He who dies with the most
Ardent Computer uunet!ardent!mec FRIENDS wins."allan@dhw68k.cts.com (Alan Perry) (12/17/88)
I always thought 4 with the correct answer. Ever since I first starting
writing in C I have used 4-space indentation. I started doing it this
way because all of the C code written by others where I went to school
was indented by 4.
I don't know where this indent by a full tab came from, but I have a
problem controlling my gag reflex whenever I see it.
--
--------------------------------------------------------------
alan perry UUCP: {trwrb,hplabs}!felix!dhw68k!allan
Internet: allan@dhw68k.cts.commat@mole-end.UUCP (Mark A Terribile) (12/18/88)
> (plus various other things) I only feel strongly about a few > indentation issues: ... > Like everyone else said, having an indentation standard is more > important than what the standard says. However, when you get into the > topic of function and module headers, you will probably find more of a > religious war, ... > > These standards are crucial - you can't run code through a pretty-printer > and get comments out. ... they should be flexible - decide on a list of > things which can be described about ... (e.g. function arguments, return > value, side effects, global dependencies, references, description.) Then > only require those elements relevant to a particular function be put in > that function's header. There's really a lesson in all this, even as far as coding standards are concerned: allow the flexibility to do the thing right in several ways, while making it harder to do things wrong. Let's try some ideas: When writing standards for indentation and so forth, allow several ``styles'' but require that once a given file/module/whatever has been begun in one, subsequent changes (short of a rewrite) must be done in that same style. Decide what really HAS to be said and done. Global data structures, for example, often need six or seven times their own length in explanation. Putting the function braces in the first column helps not only some emacs- family editors, but vi as well. Functions that are meant to be called from outside their ``subsystem'' need man-page prologues. Functions that are functions only to keep another function from growing too bushy should probably be described with their caller. Functions that stand on their own, but that are meant for use anywhere within a subsystem should at least have their arguments and return values described. Tricky algorithms should be described. (But what constitutes ``tricky''?) It makes sense to have headers in the function prologue so that sections can be pulled out mechanically. It makes less sense to require that irrelevant sections be present, and less still to require that all the sections be in a fixed order. The Procrustrean approach to programming style cannot guarantee readable programs or intelligible, helpful documentation. If the ``bed'' upon which the code is forced to fit is too uncomfortable, if its cost in mental effort is too great, programmers will be distracted from the real work: writing simple, expressive code and describing it clearly and precisely. The latter point is too often neglected. I've seen a real unwillingness in code inspections to demand changes in imprecise or unclear commentary. ``Oh, give up, will you! We all know what he MEANS.'' Well, if we all knew what he meant, there'd be no need for the comments in the first place. You *can't* create an objective, checklist criterion for the style of prose in comments, but if the comments are needed at all their quality is critical, and their quality depends upon the quality of their style. > That approach is close to what I find myself doing. It also avoids the > trap mentioned in a previous discussion of coding standards - someone > worked at a place where the mandatory function headers were so long > that people combined functions to avoid writing headers. Crap of this sort extracts a high price from programmers without buying anything at all back. When you put rules and procedures in place, you should think of yourself as a shopper: you want to get the most payback at the least cost. The first thing you see on a shelf may not do that. -- (This man's opinions are his own.) From mole-end Mark Terribile
henry@utzoo.uucp (Henry Spencer) (12/18/88)
In article <879@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: >...8 columns is _way_ too big for an indentation increment. >The range recommended by everyone except C let's-torture-test-the-eyes >hackers is two to five columns for an indentation increment. 8 columns is just fine for people who split up their code into functions instead of cramming it all into giant monolithic lumps. Don't view hitting the right margin with 8-column indents as a sign of overly-big indents, view it as a sign of overly-complex code that needs to be broken up. I find that this is *almost* always the right view, in hindsight. [Boy, I can hear the afterburners lighting. Fortunately, I'll be on vacation in Australia by the time the flame war starts... :-) ] -- "God willing, we will return." | Henry Spencer at U of Toronto Zoology -Eugene Cernan, the Moon, 1972 | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
bill@twwells.uucp (T. William Wells) (12/19/88)
In article <879@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes:
: 8 columns is _way_ too big for an indentation increment.
: The range recommended by everyone except C let's-torture-test-the-eyes
: hackers is two to five columns for an indentation increment.
This is called "argument from authority". Ok, where's yours?
I routinely use 8 space indentation; I have no problem reading it
that way. On the contrary, though I can read 4 space indentation
without difficulty, anything less causes me severe problems.
I would admit that I might be an exception, being legally blind, but
knowing many programmers who also prefer 8 space indentation, who
possess normal eyesight, and no particular tendency toward rabidity,
I have to doubt that your assertion is anything more than somebody's
opinion.
---
Bill
{uunet|novavax}!proxftl!twwells!billok@quintus.uucp (Richard A. O'Keefe) (12/19/88)
In article <2477@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >In article <879@quintus.UUCP>, ok@quintus.uucp (Richard A. O'Keefe) writes: >> 8 columns is _way_ too big for an indentation increment. >Who said 8 columns? I said a tabstop. That can be anything you want. No it can't, not and expect other people to make sense of your files. I once had the extremely unpleasant experience of trying to read a large software system which had been written on VMS with an editor that took tab-stop = 4. The UNIX terminal driver didn't believe this. Neither did 'more'. And 'expand' wasn't quite the answer, either, as some of the tabs were in strings... Neither can I convert tabs to 4 if your file has been through an editor or mailer on its way to me which converts tabs to spaces (memories of DEC-10 <-> IBM/370, ugh). Nope, if I have to _read_ your files, I'm going to use 'indent'.
ok@quintus.uucp (Richard A. O'Keefe) (12/19/88)
In article <1988Dec18.003828.27013@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >In article <879@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: >>...8 columns is _way_ too big for an indentation increment. >>The range recommended by everyone except C let's-torture-test-the-eyes >>hackers is two to five columns for an indentation increment. > >8 columns is just fine for people who split up their code into functions >instead of cramming it all into giant monolithic lumps. Don't view hitting >the right margin with 8-column indents as a sign of overly-big indents, >view it as a sign of overly-complex code that needs to be broken up. I >find that this is *almost* always the right view, in hindsight. This is a complete misunderstanding of my point. My point is not that code runs off the right margin. What I'm complaining about is that 8 columns is just too big a jump for the eye. Heck, I could use Spencer's argument to justify 16-column indents. I had never seen anyone use indent-by-8 before I met C: good Fortran programmers used 2 to 5, good COBOL programmers used 2 to 5, good Algol programmers used 2 to 5, good PL/I programmers used 2 to 5, good BCPL programmers used 2 to 5, and so on. Of course, this was on mainframes, where you didn't _have_ a tab character. (Where the tab key on a keypunch took you depended on the program you had on its drum.) I personally find 2 too small and 5 too big, preferring 3 or 4. But 2 and 5 are tolerable. Fitting onto a line or not fitting onto a line, 8 is too visually tiring. Think about the size of paragraph indentation. Think about how poetry is laid out.
lew@gsg.UUCP (Paul Lew) (12/20/88)
In article <1988Dec18.003828.27013@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: > >8 columns is just fine for people who split up their code into functions >instead of cramming it all into giant monolithic lumps. Don't view hitting >the right margin with 8-column indents as a sign of overly-big indents, >view it as a sign of overly-complex code that needs to be broken up. I >find that this is *almost* always the right view, in hindsight. ditto. Once a programmer changed his tab indentation to 4 spaces and guess what happen when he tried to print the file? Most of the terminals, serial printers I have seen use 8 spaces tabs. If you use 'ed' to edit a vi file with tabstop set to 4, you better make sure your terminal is wide enough. You can not show your file on your colleague's terminal with 8 spaces tabs without extra work, you may use "set tabstop=4" in vi, but how about other tools like grep, awk? All this is just a lot of inconvenience. I think more than 5 level of indentation is too much for a function, this way you can have your code easy to write and easy to maintain. 8 spaces tabs are just right for 80 columns CRTs. Another colleage edited all his files on Sun with 132 columns windows and this made it very hard for other people to edit his files on 80 columns CRTs. An easy solution is to change tabspaces when editing files with wide lines. One great indentation style I saw recently: do { ........... ........... } while (....); It looks fine until when someone view the file happen to have the line with 'while' displayed at the top of the screen. Conclusion: you can try to educate someone but you better prepare yourself to read like C parser. -- Paul Lew {oliveb,harvard,decvax}!gsg!lew (UUCP) General Systems Group, 5 Manor Parkway, Salem, NH 03079 (603) 893-1000
peter@ficc.uu.net (Peter da Silva) (12/20/88)
In article <888@quintus.UUCP>, ok@quintus.uucp (Richard A. O'Keefe) writes: > In article <2477@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: > >In article <879@quintus.UUCP>, ok@quintus.uucp (Richard A. O'Keefe) writes: > >> 8 columns is _way_ too big for an indentation increment. > >Who said 8 columns? I said a tabstop. That can be anything you want. > No it can't, not and expect other people to make sense of your files. Yes it can, if you write the program in the expectation that tabs will change. I change tabs on the fly as I edit my program depending on nesting depth, line length, and other considerations. Thus I don't do things like: code /* Comment */ code code /* Comment */ code /* Comment */ code code code /* Comment */ > Nope, if I have to _read_ your files, I'm going to use 'indent'. Well, let me know when you actually see some. -- 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.
dhesi@bsu-cs.UUCP (Rahul Dhesi) (12/21/88)
In article <291@gsg.UUCP> lew@gsg.UUCP (Paul Lew) writes:
Once a programmer changed his tab indentation to 4 spaces and
guess what happen when he tried to print the file?...If you use
'ed' to edit a vi file with tabstop set to 4, you better make sure
your terminal is wide enough. You can not show your file on your
colleague's terminal with 8 spaces tabs without extra work...
I usually do something like this:
pr file ... | expand -3 | lpr # to print
less -x3 file ... # to send to screen
--
Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesijlh@loral.UUCP (Physically Phffft) (12/22/88)
In article <17082@dhw68k.cts.com> allan@dhw68k.cts.com (Alan Perry) writes: > >I don't know where this indent by a full tab came from, but I have a >problem controlling my gag reflex whenever I see it. > Well, when I learned C I tried to use tab stops of 4. Telling my terminal they were 4 was no problem, telling vi they were 4 was no problem, but how about lpr? or vgrind? It's been a few years now but my final impression was the UN*X world implicitly assumes tab stops of 8 and nobody needs a way to change them. (yes I know about expand, but that only solves some problems). So yes, 8 is idiotic. But compared to the hassle involved in using 4 what choice do I have? And if you use 4 spaces instead of a tab, I hope I never have to go near your code. That drives me nuts more than any other good/bad/indifferent coding style. Jim "My doctor told me to stop having those intimate dinners for 4. Unless there were 3 other people." Orson Welles. -- Jim Harkins jlh@loral.cts.com Loral Instrumentation, San Diego
rwl@uvacs.cs.Virginia.EDU (Ray Lubinsky) (12/22/88)
In article <879@quintus.UUCP>, ok@quintus.uucp (Richard A. O'Keefe) writes: : > Where'd you get the hardware upgrade for the eyes? > 8 columns is _way_ too big for an indentation increment. > The range recommended by everyone except C let's-torture-test-the-eyes > hackers is two to five columns for an indentation increment. Once you get used to 8 column indents, anything else looks like its not indented at all. The structure of a function stands out clearly; less than 8 columns is fine for write-only source code, but its a bitch to read. -- | Ray Lubinsky, UUCP: ...!uunet!virginia!uvacs!rwl | | Department of BITNET: rwl8y@virginia | | Computer Science, CSNET: rwl@cs.virginia.edu -OR- | | University of Virginia rwl%uvacs@uvaarpa.virginia.edu |
mat@mole-end.UUCP (Mark A Terribile) (12/22/88)
> >>...8 columns is _way_ too big for an [indent]. The range recommended by > >>everyone except C let's-torture-test-the-eyes hackers is two to five ... > >8 columns is just fine for people who split up their code into functions > >instead of cramming it all into giant monolithic lumps. ... > ... My point is not that code runs off the right margin. ... 8 columns > columns is just too big a jump for the eye. ... I had never seen anyone > use indent-by-8 before I met C: good Fortran programmers used 2 to 5, good > COBOL programmers used 2 to 5, good Algol programmers used 2 to 5, good > PL/I programmers used 2 to 5, good BCPL programmers used 2 to 5, ... At one time, good house paint was based on lead white. I don't find 8 columns to be torture for the eyes. Indeed, I find anything much less to be hard to see. Perhaps it's because I like to lean back and take the long view ;^} I *do* have code running off the far margins, in part because I use moderately long identifiers, in part because I use plenty of white space in line, and in part because I use the expression syntax of C (and of C++, whose expression syntax is even more potent) for all its worth *WITHOUT* becoming obscure. This means that I must split lines; I split them at points that are clearly NOT indentation columns--unless I am writing something like printf( format, key_p->mark, key_p->instances == 1 ? "" : "s", key_p->descr->use, Camb_TYPENAME( key_p->descr->type ), etc. A better question is why other languages use such small indents. In FORTRAN, of course, it's rare to see 200 lines of 10-line functions; in C it can be fairly common. The larger external compilation units will call for more levels of indentation. Moreover, up until recently, the FORTRAN ``do'' was brain-damaged and had to be protected by an ``if'' from looping once when it should loop zero times. Programmers who wrote that as two levels of control structure would end up with a double-indent; programmers who considered it a single (synthetic) control structure would write it as one. The problem of formatting ``synthesized'' control structures infects other languages as well; a pass through *The Elements of Programming Style* will show all sorts of trouble that people have made for themselves in this way. Pascal is a special case; its small-minded expression syntax and control structures are unexampled in languages written by people who ought to know better. (Yes, I'm flaming.) The inability to write short-circuit evaluations and to accomplish even modest operations like assignment inside tests forces multiple levels of ``if'' and redundant ``else'' clauses. Moreover, it forces natural operate-and-test-at-the-top loops into operate, test, set flag, if-not-flag, test-at-bottom constructions. Often three or four levels are needed to synthesize one control structure. The inability to do an early return also forces cases to be nested in if-then-elses, and the rote approach to control structure encouraged by the mess leads people to mindlessly indent else-if's whether it reflects the nature of the problem or not. I can't speak for Algol (which one?) or BCPL, but PL/I's label-directed syntax and lack (in most versions) of early exit encourage or force the same problems of synthesized control structures that plague FORTRAN; when PL/I is used for ``FORTRAN with semicolons'' the problem is even worse. COBOL is a world unto itself; even the people who continue to use it and specify it wish they had something better that ``felt'' like good old familiar COBOL and had all of the indispensible arcana that COBOL supports. It's hardly an universal example of programming style. Small indentation is an irritating solution to a family of problems that C just does not have. Why carry it around? Of course, if you are using a screen whose typeface is so poor that you have to lean 5'' close to it to read your program, then the 2-space indent is easily explained ;^} -- (This man's opinions are his own.) From mole-end Mark Terribile
funkstr@ucscb.UCSC.EDU (-=/ Larry Hastings /=-) (12/23/88)
+-In article <2891@uvacs.cs.Virginia.EDU>, rwl@uvacs.cs.Virginia.EDU (Ray Lubinsky) wrote:- +---------- | | In article <879@quintus.UUCP>, ok@quintus.uucp (Richard A. O'Keefe) writes: | : | > Where'd you get the hardware upgrade for the eyes? | > 8 columns is _way_ too big for an indentation increment. | > [deleted] | | Once you get used to 8 column indents, anything else looks like its not | indented at all. [deleted] | | -- || Ray Lubinsky, UUCP: ...!uunet!virginia!uvacs!rwl | | +---------- I don't understand what this is an issue at _all_. Everyone should merely indent all their source code, and then set the tabspace to whatever indentation increment they want. This option is available in most editors I can think of; vi has it (:set ts=#), Emacs undoubtably has it SOMEWHERE, and even Sprint has it (it's an editor variable, "tabsize", you can set it with [U]tilities/ [M]acros/[E]nter "tabsize = #"). If it isn't in your editor, then OBVIOUSLY you need a new editor...* -- /|\ /|\ .. . . . . . . . . . . | |\| |\| .. . . . . . . . . . . |/|\|/|\|/|| _ _ _ _ |_| _ _ |_ -__ _ _ARPA: funkstr@ucscb.ucsc.EDU | |/| |/|L_ (_\( ( (_/ | |(_\_) (_ || )(_)_)UUCP: *!ucbvax!ucscb!funkstr \|/ \|/ larry / hastings _/ WORK: sun!acad!metaware!funkster MetaWare Incorporated Disclaimer: It was a bad day. "If any of your OSF force are caught or killed, the Secretary will deny any knowlege of your activities." --from the new Mission: Impractical * sarcasm
bill@twwells.uucp (T. William Wells) (12/24/88)
In article <129@mole-end.UUCP> mat@mole-end.UUCP (Mark A Terribile) writes:
: Of course, if you are using a screen whose typeface is so poor that you have
: to lean 5'' close to it to read your program, then the 2-space indent is
: easily explained ;^}
Actually, I read the screen from about seven inches. I use eight
space tabs. I'm not wedded to eight, though until the standard method
of handling tabs changes I'll stick with it. And very small
indentations cause two problems:
1) It is harder to verify that things line up: the close spacing
makes it difficult to distinguish one vertical column from
another.
2) If you, as I do, write continuation lines as partially
indented, checking out indentation is even harder.
I'd guess that the smallest indentation that avoids the above problems
is four spaces.
---
Bill
{uunet|novavax}!proxftl!twwells!bill