3 ms·

I think its more that the language enforces some formatting to a degree. Other languages are very free form in how you can structure your style and where to pl

I think its more that the language enforces some formatting to a degree. Other languages are very free form in how you can structure your style and where to place your curly brace. In go it is a compiler error to deviate from their style.

Smerity 12y ago
It actually isn't a compiler error in Go to deviate from gofmt's specification* but it is a widely enforced rule in the community. Most major Go projects use gofmt and any Go code, such as the built-in libraries, are gofmt'ed. You're fighting against the tide if you format otherwise. Given that, jsfmt doesn't need 100% adoption: using it in a single project or library would still be useful. Stating new contributions must be jsfmt'ed would be less trouble than most standard pull request requirements (pass + update any relevant testing code, ...). I personally love these formatting tools and am looking forward to more of them, such as ClangFormat[1]. * You might be thinking of unused variables or imports resulting in compiler errors, which isn't the same as not compiling due to formatting? [1]: http://clang.llvm.org/docs/ClangFormat.html http://clang.llvm.org/docs/ClangFormat.html
- jzelinskie 12y ago
  How automatic semi-colon insertion works causes braces to be on the same line as a function signatures/ifs/switches/etc. This program won't compile: http://play.golang.org/p/8DSev4ZjWZ http://play.golang.org/p/8DSev4ZjWZ
- stusmall 12y ago
  What I was referring to is curly brace placement. func main() { } vs func main() { } which produces the error "prog.go:4: syntax error: unexpected semicolon or newline before {". As I understand it this is because of the rules of where it will insert semicolons. It isn't enforcing everything about the format which is why I said "to a degree" but it is still one of the most opinionated compilers on format that I know of. Either way, I'm glad they did it. The "where should the curly brace go" is one of the most annoying bike-sheds.
  - achal 12y ago
    In case anyone else thinks they're insane, the two are the same. The second one should have been func main() { }
    - stusmall 12y ago
      Oh thanks! Not sure how it got trashed.

Smerity 12y ago

It actually isn't a compiler error in Go to deviate from gofmt's specification* but it is a widely enforced rule in the community. Most major Go projects use gofmt and any Go code, such as the built-in libraries, are gofmt'ed. You're fighting against the tide if you format otherwise. Given that, jsfmt doesn't need 100% adoption: using it in a single project or library would still be useful. Stating new contributions must be jsfmt'ed would be less trouble than most standard pull request requirements (pass + update any relevant testing code, ...). I personally love these formatting tools and am looking forward to more of them, such as ClangFormat[1]. * You might be thinking of unused variables or imports resulting in compiler errors, which isn't the same as not compiling due to formatting? [1]: http://clang.llvm.org/docs/ClangFormat.html http://clang.llvm.org/docs/ClangFormat.html

jzelinskie 12y ago
How automatic semi-colon insertion works causes braces to be on the same line as a function signatures/ifs/switches/etc. This program won't compile: http://play.golang.org/p/8DSev4ZjWZ http://play.golang.org/p/8DSev4ZjWZ
stusmall 12y ago
What I was referring to is curly brace placement. func main() { } vs func main() { } which produces the error "prog.go:4: syntax error: unexpected semicolon or newline before {". As I understand it this is because of the rules of where it will insert semicolons. It isn't enforcing everything about the format which is why I said "to a degree" but it is still one of the most opinionated compilers on format that I know of. Either way, I'm glad they did it. The "where should the curly brace go" is one of the most annoying bike-sheds.
- achal 12y ago
  In case anyone else thinks they're insane, the two are the same. The second one should have been func main() { }
  - stusmall 12y ago
    Oh thanks! Not sure how it got trashed.