The Facts Behind the Code Indention Style War(experimentgarden.blogspot.com)
experimentgarden.blogspot.com
The Facts Behind the Code Indention Style War
http://experimentgarden.blogspot.com/2009/07/facts-behind-code-indention-style-war.html
28 comments
Well, we had a compilers class in college in which the professor told us to compulsorily use the K&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&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.
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.
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.)
Your editor can still show you exactly what you want to see. And other people will have the same ability.
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.
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.
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.
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.)
Your editor can still show you exactly what you want to see. And other people will have the same ability.
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.
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.
That's an interesting idea.
What about broken code, though, would I not be able to save that?
What about broken code, though, would I not be able to save that?
A block which fails to conform to the currently active syntax would get saved as a "text" expression, i.e. (STRING "....broken code...").
You can't be too rich, too thin, or have too many lines of codes visible at any resolution. Whatever indentation style puts the most readable code on my screen is my preference.
[FWIW, both examples suck. Use a case or switch statement.]
[FWIW, both examples suck. Use a case or switch statement.]
I always used to use K&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:
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 switched to Allman after that: much to the relief of many people ;)
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 switched to Allman after that: much to the relief of many people ;)
Personally, I use K&R BUT add space as appropriate to make things readable. Using BSD format, amongst other things, I find the 3 lines between the leaves of an if/else statment really start to chafe.
Having used python and small amounts of lisp, I also flirted with rolling up all the close parens/braces on the end of lines with no white space.
Having used python and small amounts of lisp, I also flirted with rolling up all the close parens/braces on the end of lines with no white space.
This is about bracing styles and your comment is about Python. That is almost a non sequitur ;)
not really - I used K&R in PHP which got me in the poor habit of compressing any code. :)
I don't know if compressing code is a bad habit. Generally the more code I can see on a screen the faster I can understand what is happening. A good way to add visual space is to supplement the extra lines Allman style would add with comments. I hate scrolling up and down constantly to see what a simple class is trying to do.
"In my opinion, the Allman brace style is easier to read because..." (blablabla)
bottomline: because he is used to them. I feel the K&R style is easier to read because that is what I am used to.
bottomline: because he is used to them. I feel the K&R style is easier to read because that is what I am used to.
Well put. Personally, I get distracted when reading Allman style. When I start scrolling, I start daydreaming about all of the wasted space and how that programmer must have met his/her line quota for the day. Most editors have a brace matching feature that helps.
Yeah while I was reading that article it occurred to me that Allman is a good way to increase LoC count ;-)
You'll also notice that in his example of the Allman style, each code block starts with a comment. In my experience as an Allman formatter, I feel pretty much compelled to comment even the simplest code blocks, just so that it doesn't look stupid, thus increasing the number of lines of code even further.
I use K&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.
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.
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.
For the reocrd, my indent settings:
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.
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.
For the reocrd, my indent settings:
-br -brs -nbfda -npsl -npcsI used to use K&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&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.
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.
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.
I've seen code that got confusing with K&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.
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've seen code that got confusing with K&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.
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.
Well I feel the block kind of belongs to the function definition/for loop/whatever, so it seems illogical to me to artificially separate them. I'd like to see what belongs together at a glance.
A single bracket on an otherwise empty line carries very little information, so why not reduce the strain on the eyes.
A single bracket on an otherwise empty line carries very little information, so why not reduce the strain on the eyes.
Because there's two types of information: control information and process information.
When I'm scanning code, lots of time I don't care about the control, I'm looking for what process takes place. Likewise, sometimes I'm just interested in control and could care less about process.
Braces-stand-alone lets me focus on each of these at a time. Especially if you get into an unusual control situation, perhaps with nested conditions, braces-stand-alone lets you isolate various control paths and change and test them.
It's not the end of the world or anything. As long as you understand the superiority of my position, of course (grin)
When I'm scanning code, lots of time I don't care about the control, I'm looking for what process takes place. Likewise, sometimes I'm just interested in control and could care less about process.
Braces-stand-alone lets me focus on each of these at a time. Especially if you get into an unusual control situation, perhaps with nested conditions, braces-stand-alone lets you isolate various control paths and change and test them.
It's not the end of the world or anything. As long as you understand the superiority of my position, of course (grin)
I must admit I don't understand how the "isolate various control paths" thing works. The other stuff I guess really depends on what you are used to. Probably I look more for indentation than for braces.
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&R style for the leading brace.
That way I can just look at the indentation to see where blocks start and end.
That way I can just look at the indentation to see where blocks start and end.
did anyone else notice the problem with this:
if(condition_variable==condition2)
/*{
//Block temporarily commented out.
condition_variable=condition1;
}*/[deleted]
if language == python:
self.smile()Sorry, was there a war? I must have missed it.
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&R) in private code and the house style in the day job.