
The Facts Behind the Code Indention Style War - InkweaverReview
http://experimentgarden.blogspot.com/2009/07/facts-behind-code-indention-style-war.html
======
dcminter
There 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.

------
vinutheraj
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 :)

------
asciilifeform
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.

~~~
moe
That's an interesting idea.

What about broken code, though, would I not be able to save that?

~~~
asciilifeform
A block which fails to conform to the currently active syntax would get saved
as a "text" expression, i.e. (STRING "....broken code...").

------
edw519
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.]

------
ErrantX
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 ;)

~~~
Confusion
This is about bracing styles and your comment is about Python. That is almost
a non sequitur ;)

~~~
ErrantX
not really - I used K&R in PHP which got me in the poor habit of compressing
_any_ code. :)

~~~
mrinterweb
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.

------
Tichy
"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.

~~~
mrinterweb
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.

~~~
Tichy
Yeah while I was reading that article it occurred to me that Allman is a good
way to increase LoC count ;-)

~~~
andygeers
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.

------
scott_s
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:

    
    
      -br -brs -nbfda -npsl -npcs

------
likpok
I 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.

------
makecheck
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.

------
DanielBMarkham
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.

~~~
Tichy
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.

~~~
DanielBMarkham
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)

~~~
Tichy
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.

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

------
DannoHung
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.

------
leecho0
did anyone else notice the problem with this:

    
    
      if(condition_variable==condition2)
      /*{
         //Block temporarily commented out.
         condition_variable=condition1;
      }*/

------
dsil
if language == python:

    
    
        self.smile()

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

