Why does Golang enforce curly bracket to not be on the next line?

Question

correct:

if(true) {  } 

incorrect:

if(true) {  } 

Why is this style enforced, does it have something to do with the language spec, or is it just because they prefer one style over another ?

Answer 1

Why are there braces but no semicolons? And why can't I put the opening brace on the next line?

Go uses brace brackets for statement grouping, a syntax familiar to programmers who have worked with any language in the C family. Semicolons, however, are for parsers, not for people, and we wanted to eliminate them as much as possible. To achieve this goal, Go borrows a trick from BCPL: the semicolons that separate statements are in the formal grammar but are injected automatically, without lookahead, by the lexer at the end of any line that could be the end of a statement. This works very well in practice but has the effect that it forces a brace style. For instance, the opening brace of a function cannot appear on a line by itself.

http://golang.org/doc/faq#semicolons

Answer 2

Most C descended languages use the style if ( <condition> ) <statement>, the statement is executed if condition is true. The statement can be either a single statement or brace enclosed block.

Go's if statements require a following brace enclosed block, not a single statement. This is to head off a common error that most style guides try to avoid by requiring that all if statements use braces.

//subtle error in C if (<condition>)   <statement1>;   <statement2>; 

Now that Go requires a brace block following the if statement the () are redundant. They only serve to help the lexer differentiate between the condition and the statement, otherwise if <condition> <statement> is hard to parse. (Where does the condition end and the statement begin?)

Now Go's authors have a decision to make:

• Keep the redundant ()
• require { to follow the <condition>

They decided redundancy was not desirable. This had a second side effect. Since there is an implicit ; at every newline, if the { is on the following line a ; gets put between the <condition> and the {. Go's authors again are faced with a decision:

• special case the parser to be smart about the <condition>; { construct
• require everyone adopt a common style of if ... { on the same line.
• require that the <condition> be on a single line.

Special casing the parser is a very bad thing. Look at the speed D and Go parsers compared to C++'s terrible parser performance. Also a uniform style is a good thing. Their ultimate decision is pretty simple given the constraints.