# How do you prefer to nest code?

This topic is 2499 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

In Java, the standard convention seems to be to place a bracket in the same line as the control statement like this:

for(int i=0;i<5;i++) {

//do action

}

I think that this style of nesting is hard to read. For me, giving the starting bracket its own line makes it much easier to see which control structures a piece of code belongs to. Am I a minority in this view? If not, then why did the cluttered version nesting seem to gain so much traction?

##### Share on other sites
My personal preference is for:

xxx { yyy { zzz; } }

That's not however the amount of indentation I prefer, but the forum code tag insisted on 4.

As for why, it saves vertical space.

##### Share on other sites
[quote name='ManaStone']
For me, giving the starting bracket its own line makes it much easierto see which control structures a piece of code belongs to.
[/quote]
I disagree - the control structure itself lets you know that there will be a block of code that follows it. Why waste a whole line to indicate the start of a block when the control structure (for/while/switch statement) already does so. The indentation level itself indicates which block you are in.

##### Share on other sites

I disagree - the control structure itself lets you know that there will be a block of code that follows it.

A lot of people say that, but i find that it's much easier for my brain to groc two parallel brackets than match keywords to brackets. Personally, i think the argument of saving space is lacking when compared to arguments based on clarity. I rarely hear people say that it's more clear when the bracket doesn't have its own line.

Though, for very short blocks that aren't nested, i often don't give it its own line. I guess it's inconsistent of me, but a two-line block does seem more clear to me with that style.

##### Share on other sites
Depends on the language, of course.

I like the following (Clojure):
 (xxx (xxx xxx xxx) (xxx (xxx (xxx xxx xxx) xxx (xxx xxx))) (xxx)) 
and (python)
 xxx xxx xxx xxx: xxx xxx xxx xxx: xxx xxx: xxx 

In C++, I generally follow the Java convention nowadays, except for the function scope:
 xxx xxx () { xxx (xxx) { xxx(); } } 

I used to prefer putting the { on its own line, but nowadays I value my vertical screen space a lot lot more than the horizontal space, so I place it on the line with the control statement.

##### Share on other sites
Just an FYI: Another way to save vertical space is to lower your font size as much as possible. In fact, i believe i read small fonts faster than large ones, so it's a win-win.

##### Share on other sites
I think that most who work on large projects with thousands of lines of code start to realize that vertical space is valuable. For me, I find my vertical space is very valuable, so I don't see a need to waste vertical space. I use correct tabbing, so I don't need a curly brace to indicate a nested scope. Removing that extra space makes reading large amounts of easier.

##### Share on other sites

Just an FYI: Another way to save vertical space is to lower your font size as much as possible. In fact, i believe i read small fonts faster than large ones, so it's a win-win.

This does not work for me. I don't have terribly good eyesight. Hell, right now I am viewing gamedev.net with (Ctrl +)x4

Like smasherprog said, at least in my own code, I use very struct indention, which makes nesting a breeze to figure out at a glance.

##### Share on other sites
I rarely ever scroll vertically in my projects even in huge files because i use the "Go to declaration", "Find references" for everything and i absolutely try to avoid to write functions that are to big. As a professor told once: "I cannot tell you if your routine has no errors, but i can tell you if it certainly has an error somewhere: Does the code have more than 50 lines?". Thats why i never use (and will use) the
 xxx (yyy) { } 

style but always give the brace its own line and maybe also because i orientate myself more using the braces and not the keywords (my eyes find matching braces extremely fast).

##### Share on other sites
It's all down to opinion, every side'll have positive things to say.

I prefer brackets on their own line. Makes it way easier to see where scopes end/start and match up. You don't have to look two or three times if there's a scope start at the end somewhere.

I even group if statements in logical groups per line like this:

 if ( ( ( expression ) || ( anotherExpression ) ) && ( thirdExpression ) ) { // do something } 

##### Share on other sites
I find the following style easier on the eyes, but then I value consistency and readability more than vertical screen space:

if ( foo ) { ... }
I would suggest convincing your boss to invest in mice with scroll wheels or monitors > 15" if you're lacking vertical space. Though I prefer to keep functions short in the first place.

##### Share on other sites

I find the following style easier on the eyes, but then I value consistency and readability more than vertical screen space:

if ( foo ) { ... }
I would suggest convincing your boss to invest in mice with scroll wheels or monitors > 15" if you're lacking vertical space. Though I prefer to keep functions short in the first place.

this

##### Share on other sites
braces on their own line for me as well, it's probably just because I'm use to it but I find it much easier to find scope when the { } are in the same column and have made mistakes in code when the opening brace is on the same line as the conditional.

Also in my C++ code I make a lot of use of nested local scope in places so having the braces in the same column in all conditions makes it consistant from a visual point of view.

And honestly, with 24" monitors and 1200 pixels of vertical space is it really such a big deal? I've never found myself wishing for more (although I also tend to write compact functions so it's not like I have to scan far from the top to the bottom) and yes, this is in large projects as well in my position of a rendering programmer.

##### Share on other sites
I really hate the "Java style" or whatever it would be called.

I just don't see how it makes any sense at all and I find it very counter-intuitive to read.

##### Share on other sites
I prefer bracket on the line with the conditional. Mentally, I consider it part of the conditional: "for bleh bleh bleh open; do this then that then the other thing" not "for bleh bleh bleh; make a block". I just don't mentally break them up that way. The whitespace from the indentation provides enough visual reference for me to line up scope. And to be honest I end up leaving a line of whitespace after the conditional anyways (when it's not another conditional), so it's not a matter of vertical real estate. Newlines are supposed to come at the end of a coherent thought and the 'begin new scope' is part and parcel to the conditional in my mind when I'm writing code.

Though sadly, all of my professional work requires them on newlines. So at least that's not so bad to read after some 4 years now. I don't have to stop at every conditional because my brain sets off 'that looks like a bug' alerts anymore...

##### Share on other sites
I prefer the One True Brace Style. It is the Only Style. All other styles are Blasphemy and Anathema and will cause you to go blind, go crazy, grow hair on your palms, and rot in Hell for Eternity.

Whichever is the One True Brace Style depends on (a) what your manager insists on and (2) what the existing code is already using.

Unless they've spent years using ed on a VT100 anybody who argues that vertical space is at a premium is just a simpering wimperer.

##### Share on other sites
Well, I said I preferred the xxx { style for the vertical space, not that I'm super religious about it. I'll happily use whatever style is already in use in the codebase or company, because as others said, consistency is much more important.

But when I get to choose, perhaps because its a personal project not relying on existing code, I'll choose the vertical space efficient variant because I like the extra vertical space. (I do use a 1600x1200 monitor fwiw)

i orientate myself more using the braces and not the keywords

I orientate myself through the indention, not the braces or keywords. Then if I find a brace that I can't instantly match up by following the indention, I use brace matching. When I code in Clojure, which is much heavier on parentheses, I use rainbow parentheses which makes it instantly obvious which '(' matches which ')'.

anybody who argues that vertical space is at a premium is just a simpering wimperer.

I code on a desktop and on a netbook. On the netbook, vertical space is very very limited, especially if I use anything other than a terminal-based editor (because GUI editors like to have tool bars and such). Even on the 1600x1200 monitor I find that vertical space is limited, especially when using an IDE like Visual Studio or Eclipse, with the extra panels and toolbars taking up a lot of screen space.

Is it a huge deal? No. I'll use what you called the one true style. Of course it makes sense to stay consistent with what your project, team or company uses. This thread asked what we preferred and I prefer the extra space - not need it.

I hate when functions are not wholly visible on screen. I also like largeish font sizes because my eyesight isn't the best.

Anyway, to each his/her own

##### Share on other sites

And honestly, with 24" monitors and 1200 pixels of vertical space is it really such a big deal? I've never found myself wishing for more (although I also tend to write compact functions so it's not like I have to scan far from the top to the bottom) and yes, this is in large projects as well in my position of a rendering programmer.

I use Vim. When in Windows, this tiny little box pops up and floats on the screen and i can resize it, but because of navigation issues i have with Windows, i find that less convenient. So no matter how large the monitor, i find i'm held back more by an inefficient GUI... when compared to when i work in Linux with a tiling window manager where just about the entire screen can be filled with text with minimal GUI elements. At times like that, i'm tempted to take my HD TV and use it as my primary monitor.

Not just to see more of one file on screen at once, but mostly to be able to have more of several files visible at once for reference. It's not that i don't write compact functions, it's that increasing my range of view makes me more productive in the same way that switching to a tiling window manager did, and how switching to Vim did.

##### Share on other sites
WRT vertical space vs monitor size, IDEs helpfully finding things for you etc.: No, really, honestly, vertical space is valuable - or as I tend to put it, excessive vertical space is an annoyance. Having 5-line functions occupy 5 lines instead of 10 really does make a difference. The reason: in well-organized code, functions are ordered so that you are relatively more likely to call a function that is adjacent or nearby. Shrinking the functions maximizes the probability that the function in question is already on-screen at the time that you are contemplating calling it. This is better than having a large monitor or a small font size because you do not have to strain your eyes as much. This is better than having a mouse scroll wheel because you do not have to scroll. This is better than Intellisense because you do not have to think about what the function is named (the name is already in front of you) and you do not have the visual distraction of Intellisense popping things up that obstruct the code you were just working on.

In my experience, a compact vertical style does not lead to writing longer functions. If anything, it leads to writing shorter functions, because (a) an over-long function is even more intimidating in a compact style because of the wall-of-text phenomenon; (b) one comes to realize that the benefit mentioned above depends on also having short functions.

Finally, this style visually emphasizes function boundaries, since there are fewer places where things are as spaced-out vertically as they are at the function boundaries. I find this aesthetically pleasing and useful for reference, to the point where I have started allowing myself a bit of extra vertical space in the form of a double blank line between functions (which also allows for single blank lines to delimit sections of over-long functions that haven't been refactored properly yet - I am not yet sure whether this makes me complacent in postponing that refactoring, or whether it helps psychologically with the task of refactoring).

I may be an old curmudgeon, but my opinion is informed by years of actual experience trying this stuff.

##### Share on other sites

I may be an old curmudgeon, but my opinion is informed by years of actual experience trying this stuff.

Another word for experience is reenforcement. Of course if you do something one way for years and years, you're going to find ways in which it makes your life better. I have a lot less experience than you (most likely), but my experience leads to the exact opposite conclusion. I think we can find more objective ways of looking at it. Actually, i'm pretty sure there have been some studies, but i couldn't find any when i googled it.

But let's not continue discussing this as a false dichotomy. You can have parallel braces AND save vertical space by using the Horstmann Style. Personally, i find that surprisingly readable. I can see myself years down the line using it primarily.

Reading that article, i'm reminded of another reason i like the (what the article calls the) Allman style:

if( some long condition && more of the same ) { actual code }
Here, the braces actually help me spatially identify where the condition actually ends. Since i indent the extra line on the if the same amount as the actual block of code, i would otherwise have to put a line between the condition and block anyway to keep them distinguishable. Of course, it would be more consistent if i wrote it like
if ( some long condition && more of the same ) { actual code }
but obviously a line has to be drawn somewhere.

Just for comparison: if( some long condition && more of the same ) { actual code }