Live data from Hacker News

The Facts Behind the Code Indention Style War

experimentgarden.blogspot.com

11–20 of 29 posts

Re: The Facts Behind the Code Indention Style War

#11
post #2

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

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

Re: The Facts Behind the Code Indention Style War

#12
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 :)

Re: The Facts Behind the Code Indention Style War

#13
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.

Re: The Facts Behind the Code Indention Style War

#15

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 sho…

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.

Re: The Facts Behind the Code Indention Style War

#16
post #11

Earlier quoted context omitted.

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.

Re: The Facts Behind the Code Indention Style War

#17
post #14

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

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.

Re: The Facts Behind the Code Indention Style War

#19
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.

Re: The Facts Behind the Code Indention Style War

#20
post #14

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

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 ;-)
Post reply on HN