Brace styles

[blahblahblahh]

[quote]With most code editors now allowing for “folding code” (that is to say, a little plus-sign twiddle that allows you to hide the code between the braces at your discretion) I find there is no reason to worry about vertical space.
[/quote]
The most ancient of the few C++ gurus I know used to agree that the main reason for style 1 was back in the day of poor IDE’s, where it was a distinct time-saver to reduce the number of lines in your source code, and save you all that scrolling!

Back when C++ was pretty new, things like this became a de-facto standard because they were most appropriate for the tools people were using. Similarly, it was back in those Dark Ages that super-short variable names were invented, which included FULL type information for the variable, using one-letter codes.

E.g.:

  public static final boolean[] pSfbAmyArray;

When you can’t do syntax-highlighting, and your compiler isn’t too hot at “invalid type conversions”, things like that can be a life saver. But for normal people nowadays it’s just silly.

Equally, the fear that some people still have of writing any variable name more than about 6 characters long used to be valid. But really - is it that hard to learn to hit the TAB key? (or ctrl-space if you’ve been trained by MSVC)?

[blahblahblahh]

[quote]I used to mildly prefer #1 but now I strongly do. The main reason for that change is the way IDEA handles code folding:
[/quote]
:(. Sounds like a bug, rather than a feature (if it’s deliberate, it should at least be configurable).

Syntactically, the two styles are identical. So, an IDE should not differentiate between them.

[sugarshark]

I prefer style #1. Coming from an Unix background, where all the C code is in K&R style, this #2 ‘braces on extra lines’ style wastes space and just makes my eyes ache

But for method declarations which extend to the next line I place the brace on an extra line like this:

public void computeSomething(String name, List list)
    throws SomeException, OtherException
{
}

With the checkstyle tool this method is called nlow.

This is an never ending subject, because everyone, including me, has strong preferences how code should look like. Which is quite understandable if you work with code every day of your life. That these preferences can change over time does not hinder people to promote their current ones with religious fever ;D

[larry]

geez - you guys just have too much time on your hands!
isnt this forum for people developing cutting-edge AI algorithms and Phong shaded j2me clients which make coffee on sundays and public holidays ? ;D

just kidding - its amazing how this argument surfaces over and over again!

Ive worked on some anal projects where the team leader enforces a specific style. Personally I prefer #2 and find #1 archaic and deperecated.

more importantly than syntax, is clean code design and good javadocing.

[Mojomonkey]

What I find humourous about this is that I use the:

block {
}

style… the reason I code this way is that is the default way Eclipse formats code, and I’m waaay to lazy to change it.

But as has been mentioned, I don’t think it matters as long as it is consistent through the file(s), and across the dev team. There is nothing worse than reading Joe Smith’s code and then reading John Jone’s code which is a completely different style.

[nech_neb]

[quote]Nr 1 as it is the java standard ;D

http://java.sun.com/docs/codeconv/
[/quote]
I had this arguement with my team leader the other day.
He prefered #1, I prefered #2.

He sent me this exact link…
Now, correct me if I’m wrong (seeing how I just browsed
through it) but nothing in the document explicitly states
the use of the braces to be coding convention #1.

All the examples are given in Convention #1, but
the examples are mainly used for showing a
specific convention not related to the braces
convention.

Anyways, I guess I jumped on this thread a bit late…
hopefully someone still reads it

[leknor]

[quote]Now, correct me if I’m wrong (seeing how I just browsed through it) but nothing in the document explicitly states the use of the braces to be coding convention #1.
[/quote]
See the second bullet: “Open brace “{” appears at the end of the same line as the declaration statement”

[nech_neb]

See the second bullet: “Open brace “{” appears at the end of the same line as the declaration statement”

Ahh, I stand corrected…

But just to argue for arguing’s sake,
This is only for class and interface declaration.
one could argue that the rules do not specificly
apply to scope blocks.

[nickdotjava]

He he he… This thread will never die. I’ve created a monster! MWA HA HA HA HA!

But from what I’ve read, #2 is more commonly used. So what good’s a convention if the majority doesn’t follow it?

Oh, and I use #2. ;D

[Mojomonkey]

[quote]So what good’s a convention if the majority doesn’t follow it?
[/quote]
It doesn’t matter what the majority is following, only matters for what your team is following. IMHO It’s not important to define a standard across the board, only standardize for a project.

[leknor]

[quote]But just to argue for arguing’s sake, This is only for class and interface declaration.
[/quote]
I read that to mean “declarations in a class or an interface” which expands the scope from just the class or interface line to the whole body of class/interface.

[quote]one could argue that the rules do not specificly apply to scope blocks.
[/quote]
True, but you can infer. Eg: an if statement looks like:

[quote]if (condition) {
statements;
}
[/quote]
so if you remove the "if (contition) " you have:

[quote]{
statements;
}
[/quote]
I don’t think the Sun Code Conventions are ambigious, I think they wanted to keep the spec from being too long and expect you to exert the brain power to infer the details where they are not explicit. Who really wants to read 200 pages on exact code conventsions? I know I think the 20 they already have are more than I care to read again.

[jtr]

Being an old unix hacker, I use #1 but follow the conventions of the project.

BTW: checkstyle (http://checkstyle.sf.net) includes a brace checker which
is rather useful. There will also be an indention checker in the 3.2
release (which is also good for more religious wars).

[Markus_Persson]

I use #2.

Partly because that’s what I “grew up with” as a programmer, and partly because it feels kinda naughty to go against Sun.
It makes me feel kinda like a rebel, instead of an underpaid code monkey boy. ;D

[tortoise]

After years of coding I still find #1 completely unreadable. For the life of me I can’t understand why people use it. If you need your IDE to point out where your blocks start and stop, something’s wrong

But there are even worse styles out there, like the dreaded

void
someFunction() {
}

If memory serves isn’t that also gnu? or even weirder

public
void someFunction() {
}

[Kevdog]

Ooo… can’t let this one slip by:

I use #1 and so do most (all?) of the people I work with. #2 wastes lines, especially on nested ifs!

if (test1)
{
if (test2)
{
//do something
} else
{
//do something else
}
} else
{
// do a third thing
}

Looks sooo much better as:

if (test1) {
if (test2) {
//do something
} else {
//do something else
}
} else {
// do a third thing
}

I never need my editor to line up the blocks… amazingly my eye can line up the indentations just fine.

if (isTrue()) {
// do something
}

See, the if lines up with the brace

If you really do work where the styles vary, just use Jalopy, the java code formatter. Once you set it up, you can easily convert back and forth between styles (and not just for braces, but for all the other bad habits people have). Pick a common style (recommend Sun’s conventions) and have people convert back and forth as they check it out/back in from source control. It works great and also integrates into many IDEs

I used it to clean up 1950 classes which had this as the if-else indentation style! (Used the command line version and it only took a few mins )

if (test1) {

} else
if (test2) {

} else
    if (test3) {
    }

That code was generated by an IDE of all things (VisualAge for java) and there was no way to turn it off (it’s a really old version of VisualAge).

[swpalmer]

Hehe, this is fun…

If you think THAT wastes space, you should see how my friend codes… He argues that you have to scroll vertically no matter what so he breaks lines all over the place “consistently” so you are reading vertically practically…

e.g. any function with more than one parameter has each parameter on a separate line, the close ); is on a line by itself. Function declarations are split with the return type on a line by itself, and the parameters on their own lines. These lines are split even if they can fit easily within a single line of < 80 columns. he says people have their editor windows at different widths etc, but everyone is used to vertical scrolling, long lines that don’t fit completely on the display are always irritating, etc… blah blah…

I think it is butt ugly and much harder to read :)… but I draw the line at not aligning the braces… leaving the { dangling on the end of the line makes it harder to recognize blocks from single lines particularly when you have a blank line after the first line of the block.

[Markus_Persson]

I use #1 and so do most (all?) of the people I work with. #2 wastes lines, especially on nested ifs!

Heh, I’m even worse than your example. I put the else on its own line.

}
else
{

[Markus_Persson]

Anyway, the argument that should win this for us #2’s pretty quick: (haha, right)

Everyone probably agrees that a free standing block should look like this:

foo();
bar();
{
    Cat tempCat = CatFactory.getDefault().newCat();
    foo(tempCat, Cat.BITE_EXPENSIVE_CORD);
}
foo();

ie the { and the } on their own lines, and the contents of the block pulled in n spaces.

And even though you’re not supposed to use them, everyone probably agrees that an “unblocked” if should look like this:

if (weather.isNice())
   setState(State.HOT | State.HEAVY);
else
   setState(new EmotionState("Awww.."));

ie the statement after the if is on a separate line, and is pulled in n spaces.

Well, the killer argument is that a block is really a multi-statement/multi-line statement, and by putting the { on the same line as the if, you’re basically doing

if (evidence.isGettingWeak()) startWrappingUp(); else keepPushing();

The fact that the block contains newlines so it looks better is just a coincidence. Advocates of #1 would probably consider the following perfectly fine:

if (notSureWhatToDo) {} else {}

…

Actually, I think this all means that the GNU style is the “best” way… Hm.
Damn.

[jbanes]

Your unblocked is wrong. It should look like this:

if (weather.isNice()) setState(State.HOT | State.HEAVY);
else setState(new EmotionState("Awww.."));

If you want new lines, it won’t kill you to use braces:

if (weather.isNice())
{
   setState(State.HOT | State.HEAVY);
}
else
{
   setState(new EmotionState("Awww.."));
}

[Markus_Persson]

Agreed, it won’t kill me, but the argument won’t be as amusing.