Hacker News Reader

Comment by deweerdt | Hacker News Reader

I think that gofmt is particularly innovative, in the sense that it acknowledges that formatting is integral part of the language.

In the sense that a programming language is not only made to be parsed by a computer, but also read back by a human.

View on HN

Yes, and that the nuances of how things are formatted are really not that important, but rather having a standard which provides a consistent reading experience is the important aspect.

I agree completely with this. After fighting over code formatting for so long (often starting those fights myself), I have thankfully come to realize that what format you use almost never matters, only that you use some standardized format.

And in the case of go that standard is language wide, not just project, team, or company wide.

Except the go standard is awful, so a language-wide formatting requirement with bad defaults makes the language basically unusable (since programs are made to be read, not run).

I think that's one of the best contributions golang has made to the programming world. The idea that the language itself should be easy and unambiguous for the compiler and the human to parse. And that a single formatting standard makes life easier for everyone.

If we ever move beyond using text files for storing code, we could eliminate formatting differences entirely... but efforts in that direction have run into many issues in the past.

Rust does something similar. It doesn't allow for brace-less clauses and it also bitches and moans at you about 'miss-using' camelCase, snake_case, etc. Which is great because it means that by default all project will follow a similar mark-up.

We also have 'rustfmt' in development, which goes even further than the built-in lints.

Actually for C there has always been GNU indent, which serves a similar function as gofmt.

> I think that gofmt is particularly innovative, in the sense that it acknowledges that formatting is integral part of the language.

gofmt is still optional. Python significant white spaces are not.

I thought that the go compiler would throw an error of your code is not in the format produced by gofmt. You don't need to use the tool, but you need to have your code in the same format that the tool would produce.

> I thought that the go compiler would throw an error of your code is not in the format produced by gofmt.

This is not the case.

Nope. The gofmt-contract is a purely social one. But it's one held by nearly the entire go community which probably gave you that impression for good reason.

Wow, true. The first thing that I read was how to set up emacs to run gofmt every time you save a src file. After that, I never questioned it.

Reply on news.ycombinator.com