eric@snark.UUCP (Eric S. Raymond) (12/22/88)
The two most important thing to remember about style standards are:
1. Their payoff is in inverse proportion to the shop's average skill level,
and
2. Style standards imposed from above don't work and breed resentment.
I wrote most of a book on portable C coding once. We deliberately avoided
issuing any fiats about indentation beyond "be consistent!", knowing they
would be a pointless and losing proposition.
That having been said, I will now shamelessly plug for *my* one personal
style crotchet ;-). Religious flames will be ignored but I am genuinely
interested in what y'all think of my aesthetic arguments.
In general, I code in what I think of as "BSD/Allman" style with 4-space
indent:
int samplefunc(arg1, arg2)
char *arg1; /* args start after a tab column */
int arg1;
{
int foo; /* a blank line separates auto declares from code */
if (ifcond) /* extra spaces around conditionals annoy me */
{
for (i = startval; i < endval; i++) /* note space after ; */
{
switch (val) /* indent cases at same level as switch */
{
case VAL1:
c = b + a; /* note spaces around = and + */
break;
case VAL2:
function(arg1, arg2); /* no space before ( */
break;
default:
break;
}
}
}
}
Simple, clean, and editor-friendly. The fact that I was a LISP and Pascal
hack before I learned C is not irrelevant :-). Here's my one crotchet: I
like to write
do {
/* interior-stuff */
} while
(condition);
Why? Well, first of all, I strongly dislike do-layouts that crowd the condition
up against code in the do-scope, like:
do {
/* if there's lots of busy stuff */
/* happening inside the do block */
} while (the condition is hard to read)
Compare this with
do {
/* if there's lots of busy stuff */
/* happening inside the do block */
} while
(isn't this easier?) /* visually distinguish the condition part */
So the condition should be separated by one line from the block. The
reasonable choices for end-of-do-block layout are then
/* #1 */
}
while (cond)
or
/* #2 */
} while
(cond);
or
/* stuff */
}
while
(cond);
#3 strikes me as too much of a good thing. It would imply a start-of-block
layout like:
do
{
/* A */
which means I clobber 6 lines of vertical space in overhead for this one
construct -- no thanks, I've only got a 23-line screen!
#1 has the problem that the (cond) part doesn't fall on a 'natural' indent
level; everything else is at 4n stops, but it's at 4n + 7. Ugly. So I go
with #2, and I think that pretty much demands a 'do {' by symmetry.
--
Eric S. Raymond (the mad mastermind of TMN-Netnews)
Email: eric@snark.uu.net CompuServe: [72037,2306]
Post: 22 S. Warren Avenue, Malvern, PA 19355 Phone: (215)-296-5718djones@megatest.UUCP (Dave Jones) (12/23/88)
From article <eWLGd#1tHJD6=eric@snark.UUCP>, by eric@snark.UUCP (Eric S. Raymond): > I am genuinely > interested in what y'all think of my aesthetic arguments. > Looks okay with me. I would have no problem maintaining code that's formatted that way.
wjc@ho5cad.ATT.COM (Bill Carpenter) (12/28/88)
In article <eWLGd#1tHJD6=eric@snark.UUCP> eric@snark.UUCP (Eric S. Raymond) writes: > In general, I code in what I think of as "BSD/Allman" style with 4-space > indent: Given the chance, I always object to indents termed in numbers of spaces. If you had said "with 1-tab indent", I would have internalized that as "my favorite number of spaces per tab when I look at code". Are there still text/code tools thought to be reasonable which do not allow you to set your own sizes for tabs? Even if we can't solve where the curly braces go, world peace, and other hard problems, let's at least write this one off. Indenting is done with tabs, right? Not spaces, and not combos of spaces and tabs, right? -- -- Bill Carpenter att!ho5cad!wjc or attmail!bill
rfarris@serene.UUCP (Rick Farris) (12/29/88)
In article <WJC.88Dec27163645@ho5cad.ho5cad.ATT.COM> ho5cad!wjc writes: > Given the chance, I always object to indents termed in numbers of > spaces. If you had said "with 1-tab indent", I would have > internalized that as "my favorite number of spaces per tab when I > look at code". I've seen this argument come up several times now, and no one else has answered it, so, here goes: This won't work. Look at this example: if (foo == bar) TABTABTABTAB/* Those are 3 space tabs, and this fits */ if (foo == bar) T A B T A B T A B T A B/*These are 8 space tabs, and this doesn't fit worth a sh*t*/ It gets lots worse, of course, as you begin to nest. Things just don't line up. That's why I've learned to live with 8 space tabs. > Bill Carpenter att!ho5cad!wjc or attmail!bill Rick Farris RF Engineering POB M Del Mar, CA 92014 voice (619) 259-6793 rfarris@serene.cts.com ...!uunet!serene!rfarris serene.UUCP 259-7757
pierson@mist (Dan Pierson) (12/30/88)
In article <WJC.88Dec27163645@ho5cad.ho5cad.ATT.COM>, wjc@ho5cad (Bill Carpenter) writes: >Even if we can't solve where the curly braces go, world peace, and >other hard problems, let's at least write this one off. Indenting is >done with tabs, right? Not spaces, and not combos of spaces and tabs, >right? Sorry, indenting is done with whatever Emacs inserts for me after I've tuned it to my indentation style. Doing it by hand with either spaces or tabs is simply unnecessary work that distracts from the real job. -- dan In real life: Dan Pierson, Encore Computer Corporation, Research UUCP: {talcott,linus,necis,decvax}!encore!pierson Internet: pierson@multimax.encore.com
ddb@ns.UUCP (David Dyer-Bennet) (12/30/88)
In article <WJC.88Dec27163645@ho5cad.ho5cad.ATT.COM> ho5cad!wjc writes:
:Indenting is
:done with tabs, right? Not spaces, and not combos of spaces and tabs,
:right?
No, indentation is done with white space. Due to inconsistent
interpretations by various hardware and software tools, the only
reliable representation for white space is as "spaces" and "tabs"
with an implicit 8-character tab presetting. And you could argue that
tabs were too risky.
The one thing you should NEVER, UNDER ANY CIRCUMSTANCES, do is treat
the tab character as something other than a "move to the next 8-column
boundary" command. If you do, your indentation will be very badly
garbled on many, many video and hardcopy output devices. Most. Nearly
all.
--
-- David Dyer-Bennet
...!{rutgers!dayton | amdahl!ems | uunet!rosevax}!umn-cs!ns!ddb
ddb@Lynx.MN.Org, ...{amdahl,hpda}!bungia!viper!ddb
Fidonet 1:282/341.0, (612) 721-8967 hst/2400/1200/300eric@snark.UUCP (Eric S. Raymond) (12/30/88)
In article <WJC.88Dec27163645@ho5cad.ho5cad.att.com>, ho5cad!wjc writes: > Even if we can't solve where the curly braces go, world peace, and > other hard problems, let's at least write this one off. Indenting is > done with tabs, right? Not spaces, and not combos of spaces and tabs, > right? Well, if (you're using an editor sufficiently literal-minded that it doesn't automatically indent to the right mix of tabs and spaces && the editor doesn't have a re-indent-C-statement function) maybe it is, yes. On the other hand, if you're using emacs... Please, no flames about how not everybody uses emacs and 8-space tabs either; situations like this are what expand(1) is for and diff(1) can be told to ignore whitespace-only differences. All those extra spaces take up space! -- Eric S. Raymond (the mad mastermind of TMN-Netnews) Email: eric@snark.uu.net CompuServe: [72037,2306] Post: 22 S. Warren Avenue, Malvern, PA 19355 Phone: (215)-296-5718
leech@zeta.cs.unc.edu (Jonathan Leech) (01/02/89)
In article <eZRVf#X6xPL=eric@snark.UUCP> eric@snark.UUCP (Eric S. Raymond) writes: >Please, no flames about how not everybody uses emacs and 8-space tabs either; >situations like this are what expand(1) is for and diff(1) can be told to >ignore whitespace-only differences. Now if only SCCS could do this, I would be a happy camper. -- Jon Leech (leech@cs.unc.edu) __@/ ``The law of gravitation is different from many of the others... there are many places where gravity has its practical applications as far as the Universe is concerned.'' - R. P. Feynman, _The Character of Physical Law_
eric@snark.UUCP (Eric S. Raymond) (01/04/89)
In <6017@thorin.cs.unc.edu>, leech@zeta.UUCP (Jonathan Leech) writes: >In <eZRVf#X6xPL=eric@snark.UUCP> eric@snark.UUCP (Eric S. Raymond) writes: >>Please, no flames about how not everybody uses emacs and 8-space tabs either; >>situations like this are what expand(1) is for and diff(1) can be told to >>ignore whitespace-only differences. > > Now if only SCCS could do this, I would be a happy camper. Mr. Leech makes a telling point here, one I hadn't considered. Hmm. SCCS uses diff(1) to do its version comparisons. I betcha the command is generated with a sprintf(3) somewhere in delta(1). A trivial binary-edit to wedge in the -b option, and -- voila! Kluge of the Week... -- Eric S. Raymond (the mad mastermind of TMN-Netnews) Email: eric@snark.uu.net CompuServe: [72037,2306] Post: 22 S. Warren Avenue, Malvern, PA 19355 Phone: (215)-296-5718
desnoyer@Apple.COM (Peter Desnoyers) (01/04/89)
On the subject of tabs vs. spaces: In some environments (e.g. MPW on the Macintosh) tab size is an attribute of a file. It is perfectly reasonable to use a tab-stop of four in this case, as it will be accepted by any editor as well as the printer. On Unix and some other systems, tab size is not inherent in a file, but rather in options/commands to the various editing, viewing, and printing utilities used with it. In addition, some of these utilities (lpr) may only understand 8-space tabs. All in all, the best solution under Unix is probably to use a tab-stop of 8, regardless of how many spaces you indent. (What? your editor doesn't indent for you and you have to type those spaces by hand?!) Peter Desnoyers