The Facts Behind the Code Indention Style War

There don't seem to be any pertinent facts in that article, so it's a bit of a misnomer.<p>I'd be interested in seeing some actual research into the relative usability and other factors of the various approaches. Until such time as someone proves it objectively one way or the other I'll use what I'm familiar with (K&#38;R) in private code and the house style in the day job.

Well, we had a compilers class in college in which the professor told us to compulsorily use the K&#38;R style or he would cut marks(!!). He even made his TA write a C code which would check whether we were following the code style. So mischievous as we were, my friend and I used yacc and flex and wrote something which would make code, written in any style, into the K&#38;R style and sent it to all our friends, that was really fun :)

Tabs vs. spaces would not be an issue if we let go of the stone-age practice of storing source code as text files.<p>Every moment you spend cleaning up Windows-style EOL characters or transforming tabs into spaces (or vice versa) - or programming your editor to do so - is a moment of your life that could have been put to a better use.<p>With a standardized S-expression format (it could even be human-readable, as for example, Lisp source is) all possible source files which result in the same syntax tree would have the same canonical (by definition) representation. Yes, this means that parsers will need to parse comments rather than toss them, but implementing this minor trick is not a challenge for anyone who has read a few chapters of the Dragon Book (or its imitators.)<p>Your editor can still show you exactly what you want to see. And other people will have the same ability.<p>If you are using Eclipse (or whatnot) to magically reformat source to your personal tastes every time you edit anything, you have already quit pretending that the original raw human-readable representation is worth much. All I'm suggesting is to take this process to its logical conclusion.<p>Storing source as ASTs instead of ASCII would, among other things, increase the usefulness of revision control systems. It would eliminate the need for programmers to agree on any formatting style at all.

You can't be too rich, too thin, or have too many lines of codes visible at <i>any</i> resolution. Whatever indentation style puts the most readable code on my screen is my preference.<p>[FWIW, <i>both</i> examples suck. Use a case or switch statement.]

I always used to use K&#38;R style and I think it teaches bad habits: I used to obsess about compressing code. I remember when I started trying to help people with learning Python. A friend, and arguably better (python) programmer, commented:<p><i>Go Tom, great stuff. Now all we've got to do convince is teach you to space it all out so I can read it</i><p>I switched to Allman after that: much to the relief of many people ;)

"In my opinion, the Allman brace style is easier to read because..." (blablabla)<p>bottomline: because he is used to them. I feel the K&#38;R style is easier to read because that is what I am used to.

I use K&#38;R style for control structures (loops, if/else), but function braces get their own line. Braces for classes, structs and namespaces go on the same line.<p>I'm not worried about obsessing about compact code; this style just looks best to me. I'm consistent with my formatting, so I can glance at my code and know what I'm looking at. Actually, I can literally unfocus my eyes and I still know if I'm looking at a function, control structure within a function, or a class definition.<p>The important part, where taste comes in, is where code gets separated by empty lines. I consider code separated by empty lines akin to paragraphs.<p>For the reocrd, my indent settings:<p><pre><code> -br -brs -nbfda -npsl -npcs</code></pre>

I used to use K&#38;R, but then I discovered a useful fact that in Allman, you can comment out blocks very easily. This lets you play around with control flow in a simpler way than is possible in K&#38;R et al.

I used to have big problems with bracing styles, but for me modern text editors have basically solved them. I can match braces and colorize code, so pretty much anything is readable.<p>And ultimately, consistency is most important. Your "style" only matters when you're starting your own project; I really hate it when people let their personal disagreements chop up a source file.

I'm a braces-stand-alone person.<p>I've seen code that got confusing with K&#38;R, especially when the programmer forgot to indent the next lines. And I really like the ability to adjust control flow with block commenting you have with braces-stand-alone.<p>I'm not looking to compress code. My goal is to make code as readable as possible. Anything I can do to make it explicitly clear what's going on I'm going to do. Code should not read like a mystery novel.

I use Allman exactly because it's more spacious. But I adapt, at work for instance.

I've always liked putting the closing brace at the same indentation level as the code on its own separate line, but using K&#38;R style for the leading brace.<p>That way I can just look at the indentation to see where blocks start and end.

did anyone else notice the problem with this:<p><pre><code> if(condition_variable==condition2) /*{ //Block temporarily commented out. condition_variable=condition1; }*/</code></pre>

if language == python:<p><pre><code> self.smile()</code></pre>

Sorry, was there a war? I must have missed it.