Brace styles

[leknor]

But just to argue for arguing's sake, This is only for class and interface declaration.

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.

one could argue that the rules do not specificly apply to scope blocks.

True, but you can infer. Eg: an if statement looks like:

if (condition) {
   statements;
}

so if you remove the "if (contition) " you have:

{
   statements;
}

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.  

Games published by our own members! Check 'em out!

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

1   2   3

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

1   2   3   4   5   6   7

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:

1   2   3   4

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

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

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

1   2

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:

1   2   3   4   5   6   7   8

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.

Games published by our own members! Check 'em out!

[nickdotjava]

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

1   2   3

} else {

I do the same thing with the else.  Every brace gets its own line.  

[EgonOlsen]

everyone probably agrees that an "unblocked" if should look like this:

No, i agree that everyone who uses "unblocked" ifs should be shot anyway... ;D

[Markus_Persson]

*quickly cleans up code*

[nech_neb]

No, i agree that everyone who uses "unblocked" ifs should be shot anyway... ;D

That's some harsh words over personal preference...

I personally feel unblocked one liner ifs makes
things more readable.

Feel free to flame me now...
;D

[Mojomonkey]

I said it before in this thread, and I'll say it again. I really don't think it matters one way or another, as long as you are consistent and all who contibute code use the same style.

[swpalmer]

YOU FOOL!




Actual code from my friends C++ project.. this is how he writes it, I have not added any line breaks:

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20   21   22   23   24   25   26   27   28   29   30   31

// removed beginning of function...       hRes = m_pDevice->QueryInterface(                                                 __uuidof( IMyGraphics ),                                                 (void**)&pGFX                                                 );       if( !SUCCEEDED( hRes ) )             throw _com_error( hRes );       // <removed real comment>       m_pGFX = pGFX;       hRes = pGFX->Release();       if( !SUCCEEDED( hRes ) )             throw _com_error( hRes ); } void MyDevice::FreeResources(       void       ) { } void MyDevice::CollectInfo(       void       ) {       m_DeviceInfo = m_pDevice->QueryInformation();       m_StreamInfo = m_pStream->QueryInformation(); }

oh yeah - if he had a multi-line 'if' it would have the braces lined up - the one part where I agree with him
Could you force yourself to conform to this style? - I can't.

[tom]

I started out using #2, and for a long time I detested reading #1 code. But I switched to #1 because most of my coworkers and the java stander used it. Now I don't realy have a personal preferance.

It's a question about habit, not what is best.

[PlanetMongo]

I like #2, and is what I use at my job.  As for wasted "space", folks, 19" monitors are dirt cheap at Best Buy and they handle 1600x1200 just fine.  Or get a used, cheap one from someone upgrading to dual LCD's or something.  Just get one of those and maximize your IDE and any arguments about "wasting vertical space" should be alleviated.   I've never "bought" the whole "wasted space" argument for something as minor as starting the code block on its own line and have always had a problem with #1 style since my earliest tinkerings in C (back in 1991, freshman year of college).  I find skimming through code formatted with #2 is just faster and more efficient from a maintainability standpoint than #1.  But maybe I'm just odd.

[nickdotjava]

I like #2, and is what I use at my job.  As for wasted "space", folks, 19" monitors are dirt cheap at Best Buy and they handle 1600x1200 just fine.  Or get a used, cheap one from someone upgrading to dual LCD's or something.  Just get one of those and maximize your IDE and any arguments about "wasting vertical space" should be alleviated.   I've never "bought" the whole "wasted space" argument for something as minor as starting the code block on its own line and have always had a problem with #1 style since my earliest tinkerings in C (back in 1991, freshman year of college).  I find skimming through code formatted with #2 is just faster and more efficient from a maintainability standpoint than #1.  But maybe I'm just odd.

Mongo, I completely agree with you.  #1 sucks.  

[tortoise]

I find skimming through code formatted with #2 is just faster and more efficient from a maintainability standpoint than #1.  But maybe I'm just odd.

Absolutely. The blocks stick out plain as day. With #1 if there's any amount of nesting of blocks I have to stop and follow it fairly carefully, especially if I didn't write the code. Most people who are fans of #1 are usually fans of no extra linefeeds whatsogoddamnever too!

But now that most IDEs can reformat code in seconds, it doesn't bother me so much.

[Raghar]

Oh boys. Using 1 is much better you know, at least much better than read C++ code especially open source.
Best is to have IDE that could reformat code to your style and then back to original. In most cases you are responsible for the class file and you do every modification yourself.
[CODE]
public void meth(){
  somedeclaration;
  int c4=(int) log(c6);
  for(int c7=0;c7<12366;c7++){
     callsomethingweird(c4);
   }
}
[/CODE]
my programs look better after dissasambly, but I hardly do mistake. I lost most time becouse I didn't believe there wasn't mistake. And was lazy to use out.println();

[NexusOne]

come on people, #1 is the way to go....#2 reminds me of a double negative.

public void foo()
{
    //blah
}

is readable, but the braces do not have to be lined up because in

public void foo(){
    //blah
}

the exact start of the function already lines up with the exact end, and doesnt this just make sense? i'm sure you all realize this but it's more symmetrical to have ONE start line and ONE end line.


symbols such as { && ||, etc really shouldnt start their own lines, just as the words "including", "and", and "or" do not properly begin sentences in English.

thats why I prefer

public void foo(args){
    if(long boolean statement one &&
         long boolean statement two){
    }
    else if(boolean){
    }
}

over this monstrosity:

public void foo(args)
{
    if(long boolean statement one
    &&  long boolean statement two)
    {
    }
    else if(boolean)
    {
    }
}

[kevglass]

Which brings us round to another pathetically silly point:

spaces and lining things up

This above:

1   2   3   4   5   6   7

public void foo(args){      if(long boolean statement one &&      long boolean statement two){      }      else if(boolean){      } }

should be written

1   2   3   4   5   6

public void foo(args) {       if (long boolean statement one &&           long boolean statement two) {       } else if (boolean) {       } }

And when I say should I mean, thats the way I do it

Kev

[Matzon]

And when I say should I mean, thats the way I do it

Me too, that ought to be enough people to make it a fact, ehh?

[cfmdobbie]

Oh, no.  When wrapping a single statement over multiple lines, you have to indent it twice.  Or even better, avoid it!  Chances are you probably should break that statement up into smaller chunks anyway.

And the boolean condition definitely goes on the second line, to improve readability.  You don't say "chips and, peas" rather than "chips, and peas" do you?

[kevglass]

I wouldn't put a comma in either  

Kev

[cfmdobbie]

No, neither would I - it's only there for emphasis...

[blahblahblahh]

come on people, #1 is the way to go....#2 reminds me of a double negative.
...
the exact start of the function already lines up with the exact end, and doesnt this just make sense? i'm sure you all realize this but it's more symmetrical to have ONE start line and ONE end line.

Sorry, I'm bored; waiting for a server to crash, so I can view the logfiles (I've just turned full debugging on). So, with nothing better to do... (don't take this too seriously)

IIRC this has already been covered. Braces ARE NOTHIGN TO DO WITH FUNCTIONS (in the general case), they merely allow multi-line statements.

Hence, the "start line" as you put it is, in fact, the opening brace NOT the function.

symbols such as { && ||, etc really shouldnt start their own lines, just as the words "including", "and", and "or" do not properly begin sentences in English.

Grammatically speaking, they actually DO start their own lines, because they are phrase-starters, and we're talking about phrases, NOT sentences.

I prefer

public void foo(args){
    if(long boolean statement one &&
         long boolean statement two){
    }

But because of early drop-out, you cannot tell at a glance down the LHS which lines will execute. This is important because speed-readers read in columns, and they have to read the LHS anyway to see the end-braces (irrespective of style).

Research into how musicians sight-read has concluded (rather unexcitingly ) that the main difference between "excellent" and "poor" sight-readers was that the really good ones scanned in an almost monotonic line across the page, NEVER going backwards. Novices darted forwards, backwards, etc, and just couldn't keep up with the music (which of course has to move forwards monotonically too).

The research was done using eye-tracking, and plotting graphs on the music of where the musician was looking over time. Interesting stuff .

[GergisKhan]

Aha.  So that's why I always botched my sight reading.  Then again, sight reading in competition is bogus, as far as I can see.

[swpalmer]

i'm sure you all realize this but it's more symmetrical to have ONE start line and ONE end line.

No, visually you break the symmetry of the braces - THEY wrap the block, not the method declaration before them

symbols such as { && ||, etc really shouldnt start their own lines, just as the words "including", "and", and "or" do not properly begin sentences in English.

thats why I prefer

public void foo(args){
    if(long boolean statement one &&
         long boolean statement two){
    }
    else if(boolean){
    }
}

over this monstrosity:

public void foo(args)
{
    if(long boolean statement one
    &&  long boolean statement two)
    {
    }
    else if(boolean)
    {
    }
}

The thing is the beginning of the line is not always equivalent to the beginning of a sentence, and there are other reason to but &&, || at the beginning of the line instead of the end.

Basically they can get 'lost' off the end of the line when you are reading code.. the end of the line is generally more jagged, and it could be of the screen entirely.  Placing the && || at the beginning, nicely aligned shows clearly in a more localised spot how the conditions are logically evaluated.

e.g.

1   2   3   4   5   6

if( long boolean statement one       && short bool       || long boolean statement two        )      {      }