if – else coding style best practices


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…

Tags: , , , , , ,

10 responses to “if – else coding style best practices”

  1. cleanclouds says :

    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.

  2. Macluq says :

    Yeah, I do the same as you.

  3. kamil says :

    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” ;)

    • lukaseder says :

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

  4. Juan Alejandro Zapeta Perez says :

    i think its a good practice, but in my netbeans is not functional, because the “Format” disordered the code.

  5. azapeta says :

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

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 1,955 other followers

%d bloggers like this: