if – else coding style best practices

Posted on by lukaseder
The following post is going to be an advanced curly-braces discussion with no right or wrong answer, just more “matter of taste”. It is about whether to put “else” (and other keywords, such as “catch”, “finally”) on a new line or not. Some may write 

if (something) {
  doIt();
} else {
  dontDoIt();
}
I, however, prefer 

if (something) {
  doIt();
} 
else {
  dontDoIt();
}
That looks silly, maybe. But what about comments? Where do they go? This somehow looks wrong to me: 

// This is the case when something happens and blah
// blah blah, and then, etc...
if (something) {
  doIt();
} else {
  // This happens only 10% of the time, and then you
  // better think twice about not doing it
  dontDoIt();
}
Isn’t the following much better? 

// This is the case when something happens and blah
// blah blah, and then, etc...
if (something) {
  doIt();
}

// This happens only 10% of the time, and then you
// better think twice about not doing it
else {
  dontDoIt();
}
In the second case, I’m really documenting the “if” and the “else” case separately. I’m not documenting the call to “dontDoIt()”. This can go further: 

// This is the case when something happens and blah
// blah blah, and then, etc...
if (something) {
  doIt();
}

// Just in case
else if (somethingElse) {
  doSomethingElse();
}

// This happens only 10% of the time, and then you
// better think twice about not doing it
else {
  dontDoIt();
}
Or with try-catch-finally: 

// Let's try doing some business
try {
  doIt();
}

// IOExceptions don't really occur
catch (IOException ignore) {}

// SQLExceptions need to be propagated
catch (SQLException e) {
  throw new RuntimeException(e);
}

// Clean up some resources
finally {
  cleanup();
}
It looks tidy, doesn’t it? As opposed to this: 

// Let's try doing some business
try {
  doIt();
} catch (IOException ignore) {
  // IOExceptions don't really occur
} catch (SQLException e) {
  // SQLExceptions need to be propagated
  throw new RuntimeException(e);
} finally {
  // Clean up some resources
  cleanup();
}
I’m curious to hear your thoughts…

Published by lukaseder

I made jOOQ

10 thoughts on “if – else coding style best practices”

  1. Your Approach is right on the money…Just a random thought:

    Following is More readable?

    // This is the case when something happens and blah
// blah blah, and then, etc...
if (true) 
{
  doIt();
}

// This happens only 10% of the time, and then you
// better think twice about not doing it
else 
{
  dontDoIt();
}

    We can spot Missing bracket error easily.

    Reply

  3. i dont think that writing sth like this is more readable

    // This is the case when something happens and blah
// blah blah, and then, etc...
if (true)
{
  doIt();
}

// This happens only 10% of the time, and then you
// better think twice about not doing it
else
{
  dontDoIt();
}

    if i write sth link this i am used to think that “if” is just “if” with no “else” part, it’s wierd for me that i have closed “if” statment and suddenly is “else” part, i must more prefer to write somethink like this:

    if (true)
{
  // This is the case when something happens and blah
  // blah blah, and then, etc...
  
  doIt();
} else {
  // This happens only 10% of the time, and then you
  // better think twice about not doing it

  dontDoIt();
}

    i mean, comments are inside “if” and “else” part, if you write comment to “if” part above “if” and comment to “else” part inside “else” it wierd too, for me..

    and maybe you should read “clean code” book which is saying (as i remember), sth like this: “good code dont need comments” ;)

    Reply

    1. If you keep if and else comments consistent, your solution is a nice way of doing it as well…

      About the comments, code can only communicate “what” is being done, hardly ever “why”. For instance, I don’t know how on earth I could write code in a way that it communicates precisely “why” a stock exchange order of clearing type code 27 needs to be grouped with all other subsequent orders of type code 27 (if and only if they have a rounding lot below 0.01), before actually unloading them within a time-frame of at most 35 seconds (fictional example in a real-life application).

      But of course, not everyone goes far beyond writing “Hello World” programs where comments are indeed unnecessary :-)

      Reply

  5. In Netbeans this is the format:

    //Netbeans Format
if (true) {
} //
// This happens only 10% of the time, and then you
// better think twice about not doing it
else if (false) {
} //
//Netbeans Format
else {
}
    Reply

Leave a Reply