Live data from Hacker News

The Facts Behind the Code Indention Style War

experimentgarden.blogspot.com

21–29 of 29 posts

Re: The Facts Behind the Code Indention Style War

#22
post #20

Earlier quoted context omitted.

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.

Re: The Facts Behind the Code Indention Style War

#26
post #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.

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)

Re: The Facts Behind the Code Indention Style War

#27

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

That's an interesting idea.

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

Re: The Facts Behind the Code Indention Style War

#28
post #15

Earlier quoted context omitted.

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.

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

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.

Re: The Facts Behind the Code Indention Style War

#29
post #27

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

That's an interesting idea. 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...").
Post reply on HN