Becauseitmoreeasilyallowsyoureyestoseethedifferentoperators.

B e c a u s e i t m o r e e a s i l y a l l o w s y o u r e y e s t o s e e t h e d i f f e r e n t o p e r a t o r s .

for (i=0; i<10; ++i) vs 
for (i = 0; i < 10; ++i)

for (i=0; i<10; ++i) vs 
for (i=0; i<10; i++)

kernel/ maintainer has this big: ===========D
arch/alpha maintainer has this big: =D
arch/arm maintainer has this big: ==D
arch/avr32 maintainer has this big: ============D
arch/blackfin maintainer has this big: ===================================D
arch/cris maintainer has this big: =D
arch/frv maintainer has this big: ====D
arch/h8300 maintainer has this big: =D
arch/ia64 maintainer has this big: ==D
arch/m32r maintainer has this big: ====D
arch/m68k maintainer has this big: ==D
arch/m68knommu maintainer has this big: =====D
arch/mips maintainer has this big: ====D
arch/parisc maintainer has this big: D
arch/powerpc maintainer has this big: ==D
arch/ppc maintainer has this big: =D
arch/s390 maintainer has this big: =D
arch/sh maintainer has this big: ====D
arch/sparc maintainer has this big: ==D
arch/sparc64 maintainer has this big: ===D
arch/um maintainer has this big: ==D
arch/v850 maintainer has this big: ===D
arch/x86 maintainer has this big: =D
arch/xtensa maintainer has this big: ==D

fs/pohmelfs maintainer has this big: =======D
drivers/block/dst/ maintainer has this big: ============D
drivers/connector maintainer has this big: ===D
drivers/w1 maintainer has this big: =======D

Chris Smith wrote at 2008-04-03 15:27:

The topic is purely subjective. I try to differentiate between style and substance why reading others' code which deviates from my (naturally) immaculate style. If you can't point to a substantial flaw in the code, let it pass. I wouldn't waste word #1 on the for loop examples.

Jonathan Pryor wrote at 2008-04-03 17:38:

Several nit picks:

1. The "non-spaced" for loop would actually be:

for(i=0;i<10;++i)

Hopefully we can agree that this sucks.

2. The "full spaced" for loop would actually be:

for ( i = 0 ; i < 10 ; ++ i )

Which I think everone would agree also sucks. (Seriously, "++ i" is an abomination, as is " ( ".)

3. Which is easier to read:

Becauseitmoreeasilyallowsyoureyestoseethedifferentoperators.

Beacuse it more easily allows your eyes to see the different operators.

The real question is: how do you insert spaces to make your code more readable (as in my 2nd sentence)?

Sadly, there is no concrete answer. I find both of your original for loops sufficiently readable, *because* they have *some* whitespace (compare to my above for-loop without whitespace).

Even in English we don't separate all tokens by spaces: semicolons, commas, and periods are not separated by whitespace (along with quotes, parens, and other characters, depending on context).

Sure , extra spaces around all characters might make sense , but it really looks weird , thus slowing down reading . ( See my point ? )

The question then becomes: what do you consider a token/"word" that must be separated by whitespace (i.e. actul words), vs tokens that don't require whitespace (commas, periods, parens, etc. in English)?

Alas, there isn't much agreement here. Personally, I think '<' should be considered a separate "word", (i.e. I prefer your 2nd original for loop), but "++" is not (i.e. "++i" not "++ i"). Opinions will vary.

4. As for ++i vs. i++, it depends on your language. In C++, *always* prefer the former, so that you don't generate unnecessary temporary objects when `i' is a user-defined type. In C, it doesn't matter.

abr wrote at 2008-04-03 19:44:

Whow! Why you guys just don't preprocess the code through some perl/emacs to output your preferred whitespace style if it matters that much?

Jonathan Pryor wrote at 2008-04-03 20:10:

To answer abr: version control history.

Needless whitespace changes in version control history *greatly* increase the difficulty of reviewing changes from prior commits (unless you use e.g. `diff -b`, which not all version control diff commands support).

What you could do is automatically reformat after checkout to your settings, then automatically reformat to the version control style before commit, but any intermediate diffs would _also_ need to be automatically reformatted as well... Which is just process overhead (not CPU process, but mental process, unless your IDE handles everything for you automatically).

Then the final killer: I haven't found a perfect auto-formater, so any attempts to automatically reformat from one style to another are bound to have some corner case that isn't handled.

Add in brace placement (same line as for or a separate line?), and even `diff -b` won't save you (as one line may get split into two or vice versa).

Matthew W. S. Bell wrote at 2008-04-03 23:18:

J. Pryor: Yes. The point is words!

Although I have my own preferred whitespace style and everyone else is clearly wrong (and should be beaten), I think the much more important thing is that the style is at least consistent within the same file/project/sub-system. Otherwise, you might as well remove all whitespace (including tabs, newlines) altogether for the good that it will do.

anonymous wrote at 2008-04-04 06:25:

To compare how big the manteiner has, the ":" where the "ascii art" start should be all aligned (of course, with spaces ;))

Someone wrote at 2008-04-04 11:22:

... and you should draw it like this: 8===D

Roman wrote at 2008-04-09 10:33:

As a software maintainer of other's code for 10 years, I prefer to have code fit to one page but not been spread over 10th pages.

The only reason for the bloated spread code is payment per size, I think.

And of cause, more compact solutions - are more preferable.