Does bracket placement affect readability?

Question

Possible Duplicates:
Formatting of if Statements
Is there a best coding style for identations (same line, next line)?
Best way to code stackoverflow style 'questions' / 'tags' rollover buttons

public void Method {

}

or

public void Method
{

}

Besides personal preference is there any benefit of one style over another? I used to swear by the second method though now use the first style for work and personal projects.

By readability I mean imagine code in those methods - if/else etc...

Answer 1

Your lines of code count will be considerably less with the first option. :)

Answer 2

First one is smaller in terms of number of lines (maybe that is why development -Java- books tend to use that syntax)

Second one is, IMHO easier to read as you always have two aligned brackets.

Anyway both of them are widely used, it's a matter of your personal preferences.

Answer 3

In the old days we used to use the first style (K & R style) because screens were smaller and code was often printed onto this stuff called paper.

These days we have big screen and the second method (ANSI style) makes it easier to see if your brackets match up.

See HERE and HERE for more information.

Answer 4

I think it is completely subjective, however, I think it is important to establish code standards for your team and have everyone use the same style. That being said I like the second one (and have made my team use it) because it seems easier to read when it is not your code.

Answer 5

I use the if statement as something to reason on in this highly emotive subject.

if (cond) {
   //code
}

by just asking what does the else statement look like? The logical extension of the above is:-

if (cond) {
   //code   
} else {
   //more code
}

Is that readable? I don't think so and its just plain ugly too.

More lines is != less readable. Hence I'd go with your latter option.

Answer 6

Google C++ Style Guide suggests

Return type on the same line as function name, parameters on the same line if they fit.

Functions look like this:

ReturnType ClassName::FunctionName(Type par_name1, Type par_name2) {
  DoSomething();
  ...
}

---

WebKit Coding Style Guidelines suggests

Function definitions: place each brace on its own line.

Right:

int main()
{
    ...
}

Wrong:

int main() {
    ...
}

They suggest braces-on-same-line for everything else, though.

---

GNU Coding Standards suggests

It is important to put the open-brace that starts the body of a C function in column one, so that they will start a defun. Several tools look for open-braces in column one to find the beginnings of C functions. These tools will not work on code not formatted that way.

Avoid putting open-brace, open-parenthesis or open-bracket in column one when they are inside a function, so that they won't start a defun. The open-brace that starts a struct body can go in column one if you find it useful to treat that definition as a defun.

It is also important for function definitions to start the name of the function in column one. This helps people to search for function definitions, and may also help certain tools recognize them. Thus, using Standard C syntax, the format is this:

static char *
concat (char *s1, char *s2)
{
  ...
}

or, if you want to use traditional C syntax, format the definition like this:

static char *
concat (s1, s2)        /* Name starts in column one here */
     char *s1, *s2;
{                     /* Open brace in column one here */
  ...
}

---

As you can see, everybody has their own opinions. Personally, I prefer the Perl-ish braces-on-same-line-except-for-else, but as long as everybody working on the code can cooperate, it really doesn't matter.

Answer 7

Personally I find the second one more readable (aligned curlys).

Its always easiest for a team to go with the defaults, and since Visual Studio and I agree on this, thats my argument. ;-)