The Facts Behind the Code Indention Style War
experimentgarden.blogspot.com
The Facts Behind the Code Indention Style War
1–10 of 29 posts
Re: The Facts Behind the Code Indention Style War
#2I 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 ;)
Re: The Facts Behind the Code Indention Style War
#3There don't seem to be any pertinent facts in that article, so it's a bit of a misnomer.
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.
Re: The Facts Behind the Code Indention Style War
#4I 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 ;)
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.
Re: The Facts Behind the Code Indention Style War
#5I 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:
-br -brs -nbfda -npsl -npcsRe: The Facts Behind the Code Indention Style War
#6I use Allman exactly because it's more spacious. But I adapt, at work for instance.
Re: The Facts Behind the Code Indention Style War
#7You 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.]
Re: The Facts Behind the Code Indention Style War
#8I 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 ;)
This is about bracing styles and your comment is about Python. That is almost a non sequitur ;)
Re: The Facts Behind the Code Indention Style War
#9I 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.
Re: The Facts Behind the Code Indention Style War
#10I 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.