Is the "curly braces always should be on the statement line" rule so important? [closed]

Question

I understand "semicolon implicit insertion", but I'm not sure it's occurs in case of function expressions.

For example, this two expressions always will interpreters equally:

Matrix.scale = function (mat, scaleX, scaleY, dest) {
// useful code
};

Matrix.scale = function (mat, scaleX, scaleY, dest)
{
// useful code
};

I like first one and I notice Google like it too: http://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml?showone=Code_formatting#Code_formatting . But my colleague displeased with this style. The question arises whether or not follow strictly this rule even if with the functions declaration or it is a tribute to uniformity and this code will not break after a tricky minification?

Semiliterate

I always use egyptian brackets, it's a matter of taste :) – Nickelsen

I think most most javascript developers have adopted the first format as convention. – Lehman

Evert is right. Read about it here: #2846783 – Lynnlynna

BTW, the first version is called "cuddled." Easier to say than "curly braces on the statement line." – Pepe

@ilollar As rsplak said, they're called Egyptian Brackets now. codinghorror.com/blog/2012/07/new-programming-jargon.html :) – Mangrove

@iKnowKungFoo This is SO - if CodingHorror says their Egyptian Brackets, then they are Egyptian Brackets. ;) – Pepe

No it isn't. What is important is that you are consistent. Coding standard have become far too much of a fetish considering that IDEs will auto-format. The real need for coding standards was in the 1970s where anything goes: Fortran programs all on one line with no spaces for example. Compared to the problems that actually led to the pressure to have coding standards we are living in a paradise today. – Lukewarm

Answer 1

Code style is just an agreement about how to format code and name variables made in:

• (Sub)community of those who's coding on this language, developing specific libraries and so on.
• Your very company.

It is hard to say, which to these two factors is more decisive, but it wouldn't be a bold statement to say that in good companies code style is closely related to the code style "in the wild". Partly this is because in good companies code is often contributed to open source and, thus, it is better not to reinvent it.

There are languages with very firm, thorough and recognized by the overwhelming majority style guides. For example, this_is_very_uncommon_to_java.

As for javascript, this is not the case. There is no such thing like abstract, general "javascript code style". The problem of bracing is still heavily discussed topic in javascript community, as well as semicolons. I guess, this is just because any other issues with js-developing are already resolved ;)

If you want advise (and it looks like you want), just find peace with your colleagues. Make any kind of agreement and follow it. This is the most important thing - good relations in team are overweighting any code styling agreements.

Disinclined

Answer 2

In other languages it might be a matter of taste, but in JS it can be a very hard to find source of an error. Consider the following snippet which might not do what one would expect on a first glance:

function foo()
{
  return
  {
    bar: 1
  };    
};

console.log(foo()); // => undefined

further reading: http://en.wikipedia.org/wiki/JavaScript_syntax (search for "semicolon insertion")

Entranceway

I don't understand the point you're trying to make. What's this have to do with cuddled formatting? – Endive

My point is that having the braces on a new line can be (under some circumstances) problematic in JS. So it's better (in my opinion, and again, in JS) to just allways have it on the right. – Entranceway

Explained by someone who should know: youtube.com/watch?v=hQVTIJBZook&t=30m38s – Entranceway

That did it! JS tricked me - I honestly never ran into that (at least with code I wrote) since I use the cuddled syntax. Thanks!! +1 – Endive

While I prefer next-line syntax for other languages, I once lost a couple of coding hours to a bug caused by this scenario ({...} on the next line after return) and that convinced me to adopt cuddled syntax for JS. – Emma

Answer 3

According to the book Code Complete, the bracket should be put on the first line (which is referred to as the control statement) because it's misleading to put in on the second line since it doesn't show the logical structure of the code. If viewed from a graphical perspective, the second approach looks like this:

Where lines A-E represent the following, which is simliar to the second approach declared in this question.

A function foo ()
B {
C     print "Hello";
D     print "World";
E }

Which you can see is misleading because you can't tell if line B is subordinate to line A or if line B is its own separate statement

EDIT: In case the image is too abstract, here's a quick explanation of why the curly bracket is often included on the first line along with the control statement

Functions have two main elements:

1. the control construct
2. the function's statements

By putting the curly bracket on the second line (line B in the image) it is neither in the control statement nor is it part of the function's statements.

EDIT 2

IMO, each line of code should have a purpose to save vertical space to view more lines at once on my screen and to preserve the logical meaning of the code. Therefore, when the brace is on the same line as the function declaration then it is thereby associated with the statement that it opens. However, when it is on a line on its own (line B in my example) AND it is not indented to show subordinance to the function declaration, then it breaks the logical meaning of the code because it is neither a associated with a control construct nor is it a function statement. So, by putting the brace on the same line as the function declaration, then every line of code serves a purpose, it holds the logical meaning of the code, and it saves my screen space.

function foo() { // brace is on the same line and it's associated with the statement that it opens
    print "Hello"; // this line does something
    print "World"; // this line does something
} // this last brace terminates the function which is part of the control construct

Fluttery

@Chiyou, what do you mean by counting and numbering? – Fluttery

I need to update the picture, row B is the bracket in the second approach. I think that will clarify things to show that putting a bracket on the second line makes things misleading since it doesn't demonstrate that it's subordinate to the control statement – Fluttery

I think it's wrong because row B can only be a curly bracket. – Ami

Here's the full explanation: http://flylib.com/books/en/2.823.1.264/1/ – Fluttery

The curly brackets are aligned with the function. In your link I don't see an example for the listing. There is always the curly bracket in the second row. – Ami

Yes, it is separate from the useful code, but it's still not part of a control construct or the function's statements. BTW, I didn't just dream up this opinion, it's based on published works, so saying "No. It's wrong" is a little ridiculous. I'm merely offering an extended explanation based on published material that explains why we programmers put the bracket on the first line. – Fluttery

Ok, my bad on the "we programmers" statement. I should have said "why some programmers put the bracket" instead. Everyone has a different style and as long as there is consistency throughout your code then everything is ok. I choose the first style because a logical argument was presented to me after reading that book and after doing further research about what others do. This answer is just an extension of what I found in that said research that I am now sharing on SO – Fluttery

Answer 4

This is 100% a taste matter. Whatever you prefer, I do agree it's preferred to be consistent. So if you're coming new to a project you really should follow the established style guide.

Datha

Answer 5

When you don't work for Google you don't need to follow that rule. It doesn't break anything. Personally I like the latter version it's one more line.

Ami

Why would you prefer it due to it's extra line? – Excise

Because it's aligned with the statement. – Ami