So in the end I stop doing it (or I let small mistakes go by) and soon enough the whole codebase is heterogeneous and looks like crap everywhere.
I don't really care about Go and never used it but this is a very good move on their part IMO. No bickering allowed, it's standard. No arguing, just run "go fmt" and you're set. Brilliant.
Imagine if novels were put through Microsoft Word spelling and grammar check just prior to publication and automatically had all the changes accepted.
The python style guide gets this right, quoting Emerson's famous maxim that "A foolish consistency is the hobgoblin of little minds."
No more arguing.
Recognize that "third party" might not mean some code base from NVIDIA or whatever, but just some code from 5 years ago in your own company.
And sure, we could enforce the same tool chain on the entire company, but then you have broken diff on probably every line of code in every repository. And the embedded guys are up in arms because it makes bad decisions for their hardware, which is limited to 40 column displays. And so on.
Go got it right. They had green field development, and made the decision on formatting then. I'm not crazy about a few of the specific choices they made, but who cares, really?
Personally, I would like a tool that inspected the code, recognized the style, and then enforced that style. Braces on the same line, well, that is how all new lines will be formatted. And so on. I live and die by source code diffs, and don't want formatting wars to break that. I also spend every day in multiple code bases not written by the company, so I already deal with different formatting styles. It ain't hard to deal with, excepting that terrible Microsoft C style of spacing ('foo( x ,y )' vs 'foo (x, y)'. My eyes can't parse that quickly because it breaks all the normal rules of punctuation that we use in English and every other computer language. (I don't know that MS invented it, it is just pervasive in their code, and it is where I usually encounter it)
All of that is not to say I completely disagree with your idea, it is attractive in a number of ways, I am just pointing out some tradeoffs (and putting the lie to your "no more arguing" ;))
It only applied to the source code for the project at hand.
In the long run it would probably be a good thing but I'm not sure I'm ready to go through the massive flamewar that would be at first.
In the end I wouldn't mind this being handled at "language" level. Maybe even a flag in GCC that would warn/error on a coding style error. It would save everybody time, resources and probably a few friendships along the way.
Just a decision, like many other, that take place at the beginning of a project.
How would you feel if I left a comment calling you a fool for writing such a remark? Now realize you're giving that same feeling to every reader you're trying to convince.
It's far more effective to point out why someone is mistaken and leave it at that, as 'pg has demonstrated over the years.
Think this is the first time I've read about someone being offended for being called a fool, maybe this is just a touchy subject for some people(not trying to be snarky)
I would gladly trade that for never having to worry about it again. ask_two peopleForTheir_opinion any YOU'LL get 3_answers. Just pick one standard and get over it.
Someday there will be a billion lines of Go and it will all be formatted to the same standard.
I assume this is referring to putting opening braces on the next line.
IIRC, this has nothing to do with the `go fmt` tool - unlike in C, this is actually a syntax error in Go: http://play.golang.org/p/bn30UNkr1z
One of the reasons for this decision is because it helps enforce a truly context-free grammar for the language.
Ironically, the fact that Go has a nearly context-free grammar is what allows tools like `go fmt` and the obsolete `go fix` to make modifications to the code deterministically, with guarantees that it will not change the behavior of the code.
B) No one feature of a grammar provides context-freedom. It's not meaningful to compare Go's grammar to another grammar; it's meaningful to compare Go's grammar as-is to the way it would be if it allowed both forms.
In this case, I believe the same-line braces rule is not strictly necessary by itself (they could have gotten a context-free grammar other ways), but this was (part of) one approach.
The only reason same-line braces are required is semicolon insertion. There are other ways to express the grammar of a language without semicolons and remain context-free.
If Python's lexer is not regular, it doesn't change the fact that the parser uses a context-free grammar over the resulting lexemes. Whether that's the right approach is an engineering tradeoff and nothing more.
https://github.com/DisposaBoy/GoSublime
It's nice not having to think about proper spacing anymore and just focusing on writing the code itself.
As a whole the toolchain makes working with Go code very convenient.
edit: aha, the article did mention "gofmt -r"
