问题
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 ?
回答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
回答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.
回答3:
I think this brace-forcing thing is just an excuse to make people that love the K&R style, to not have to see Allman style. If the designer(s) would have liked the Allman style, then he or she would have simply made the parser deal with it. Imagine if XML was written in K&R. It'd look impossible to comprehend. Allman style is much easier and quicker to read. It seems this is entirely an emotional decision. I'll make one too: ignore Go.
回答4:
It has to do with the Spec, i.e. it's not just something they built into their compilers
Semicolons
The formal grammar uses semicolons ";" as terminators in a number of productions. Go programs may omit most of these semicolons using the following two rules:
When the input is broken into tokens, a semicolon is automatically inserted into the token stream at the end of a non-blank line if the line's final token is
- an identifier
- an integer, floating-point, imaginary, rune, or string literal
- one of the keywords break, continue, fallthrough, or return
- one of the operators and delimiters ++, --, ), ], or }
To allow complex statements to occupy a single line, a semicolon may be omitted before a closing ")" or "}".
To reflect idiomatic use, code examples in this document elide semicolons using these rules.
As far as I grasped it from their talks, they wanted to get rid of formatting-discussions and extended the idea with the greation of gofmt
来源：https://stackoverflow.com/questions/17153838/why-does-golang-enforce-curly-bracket-to-not-be-on-the-next-line