Bracket Style and Indenting Code

I’ll try to keep this short. Having been coding for years I’ve seen a lot of examples of how other people write code. Now while there are certain requirements in coding, there are areas where you can inject your own person style or preference. One area that has always bugged me is how code is indented and how brackets are used to separate blocks of code. Here’s a very simple example of how I normally code a simple if/else block:

if (hours < 24 && minutes < 60 && seconds < 60)
{
 return true;
}
else
{
 return false;
}

This is known as Allman style (named after Eric Allman, the developer of sendmail). The most common variant of this would be K&R style (from Kernighan and Ritchie’s book The C Programming Language) and the same code looks like this:

if (hours < 24 && minutes < 60 && seconds < 60) {
 return true;
} else {
 return false;
}

Equivalent in every way except readability. Some people call this “The One True Brace Style” because it’s been around so long. The major difference is that the opening bracket is placed at the end of the line that the control statement is on where in Allman style the brackets are each on their own line.

To me it makes sense to make code as readable as possible by lining up brackets to match the block they go with. It becomes apparent what blocks of code belong to what conditions.

Allman style
 
K&R style

If I was to have another condition nested within the example, it would look like this:

if (hours < 24 && minutes < 60 && seconds < 60)
{
 if(hours % 2 == 0)
 {
 	return true;
 }
 else
 {
 	return false;
 }
}

Again, very readable.

The funny thing about K&R style is that its roots seems to be based in the fact that programmers used to have to deal with limited screen space and by squishing the brackets together with the blocks that they belonged to, it saved precious screen real estate. Most programmers either picked up the style they use most often from learning coding in a class or by following the examples set by others, while other programmers code for readability, especially now that space isn’t the issue it once was.

While Allman and K&R are just two of the most popular styles (see
http://en.wikipedia.org/wiki/Indent_style
and
http://en.wikipedia.org/wiki/Programming_style
for some others and a detailed explanation about the history of each)

(please pardon the less than perfect wordpress code formatting)

8 thoughts on “Bracket Style and Indenting Code”

  1. I like:
    if (hours < 24 && minutes < 60 && seconds < 60)
    {
    return true;
    } else
    {
    return false;
    }
    This way I have a straight uninterrupted line of opening and closing brackets I can follow without the else getting in the way. At the end of a brace just look right, if it is empty then its the end of the condition if not there is either the else of elseif. But all this is just personal preference really.

  2. It’s about different strokes for different folks.

    I have tried a variety of styles, and gravitate back to good old K & R (mostly). I see the structure immediately via indenting, without needing to count or balance brackets – kind of like Python with closing delimiters. Additional bracket-only lines just clutter the landscape for me (except the opening of a function definition – there it helps set that apart from control structures).

    Allman style has consistency having all braces on lines by themselves, balanced. K&R has consistency in closing braces always being at the start of a line, opening at the end, which you can treat as syntactic sugar around the control flow keywords. Each type of pattern has its positives, which appeal to some more than others.

    I disagree somewhat about formerly limited screen space as the only reason for K & R – even if you have 100 lines of code visible on a rotated 24″ screen, there is a balance for best visual comprehension between packing code too tightly and too loosely. For me, K&R works – along with leaving empty lines where ever it makes the code easier to read.

    I think it would be interesting to set up one of those eye-focus-point detectors that psychologists like to use, recording how programmers view a program – where their eyes jump as they try to absorb both the structure (forest) and the trees (individual statements and expressions). I believe that excessive vertical displacement can be a tad slower to comprehend, similar to paragraphs which are too wide.

    Allman might make it easier to find unbalanced braces – but there are editor tools to help with that, and timewise finding unbalanced braces is a small part of program review and modification.

    But your milage may vary; I don’t think there’s a universal best style. I try to follow the existing style when modifying code.

  3. or even shorter

    if (hours < 24 && minutes < 60 && seconds < 60)
    {
    if(hours % 2 == 0)
    return true;
    else
    return false;
    }

  4. lolz first style there is for nabz who just want more lines of code)) the real style is like this:
    for (int x = 0;x < 10;x++) {
    if (nab[x]) {
    blabla();
    } else {
    fgdgdg();
    }
    }

    more readabel, looks cooler also much more compresed

  5. I am fairly new to php and the tutorials I’ve viewed online sometimes leave me confused. It’s good to know this. I very much like your style of coding. I thought perhaps there were ‘standards’ or ‘rules’ to coding and I strayed from them my code wouldn’t work properly. Anyway, thanks for the time to post this.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>