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.

Answer 3

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

Answer 4

Because the google guys don't like allman style. But it's very easy to support allman style, forkGo(by @diyism) only added 12 lines of code into golang compiler.

Give a try to forkGo: https://gofork.org

forkGo support such allman style:

package main
import
(
    "fmt"
)


func main()
{
    if false
    {   fmt.Println("jack")
        fmt.Println("forkgo")
    } else
    {   fmt/
           .Println("hello")
        fmt.Println("forkgo")
    }
}

Answer 5

..."he point of using braces in the first place (i.e. making it easy to identify scope of statement blocks with braces lined up on same column), "...

agreed - very difficult if you like to align your braces to distinguish blocks