As a C coder I really wish it had a standard syntax and a similar tool to deal with that. Dealing with proper style is a constant headache among a team. And I always feel like a "coding style nazi" when I bother other people to tell them "you should put spaces here", "your braces are not in the correct position", "you shouldn't use TABs there" etc...
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.
There are tools for standardizing C formatting. Another poster mentioned indent. Clang-format [1] is very good, works with C++ as well as C, and has great editor integration. You can choose among predefined style (e.g. Google, Mozilla, LLVM style guides) or create your own and then and enforce it within a source tree very easily.
In addition to being instructions for the compiler, source is also a text designed to be read. Specifying and universally enforcing too rigid a rule-set is a bad idea. Good authors sometimes need to break rules in order to make a text better.
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."
Can you say where `go fmt` gets it wrong -- give an example. Or where a consistent formatting has gone wrong, in any language? I prefer 2 space python, but I don't have a better reason than my team, as a majority, prefer condenser line lengths, but it can be a problem having to gear up to work with a lib that follows PEP8 to the t.
I agree and disagree -- I don't like the idea of C having a standard syntax, but I would like having a simple program people run their code through the points out any format mistakes. I think in general you could easily handle this using a simple perl script or similar, just require people to run their code through it before submitting. Then it's simple, and you can just point to the program to use and policy for submitting code if someone breaks syntax.
This is conceptually nice. But consider. You want to fork a third party library. On check in you reformat the entire code base? Or, if you don't do it on initial commit, and then somebody needs to modify one line?
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" ;))
Yeah, obviously but it's not "Standard". If I do that next thing will be "but I think we should change indent option X because it's better that way".
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.
This was one of my favorite parts about jetbrains products. Auto cleanup right while you are coding. Push devs, kicking and screaming sometimes, into the pit of success.
Go fmt isn’t without it’s detractors. People complain that go fmt isn’t customizable and that it puts braces where they don’t want them. Fools.
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.
I don't think this should be taken hardly. A lot of people (from what I've seen) complain about go fmt doing things they don't like (bracing structure, indentation, etc.) For me it was no big deal since my bracing "standard" (what I did 90% of the time out of luck) is almost the same as go. And most people complaining just don't try to (ehem) go with it: once you are used to seeing your code neatly formatted automagically, always exactly the same, you start to see how neat it is. Also, being able to read other people's go code without hiccups is awesome.
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'm sure Go puts the curly's in a few incorrect places. :-)
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.
> People complain that go fmt isn’t customizable and that it puts braces where they don’t want them.
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.
It is context free. Just because two tokens (INDENT, OUTDENT) are different to lex doesn't mean the grammar isn't context free.
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.
IMO that article doesn't really say anything interesting. There is no clear dividing line between the lexer, the parser, and semantic analysis. You have a great deal of freedom to move work between these phases, and what the grammar you're using at the parser level looks like can change drastically as a result.
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.
You can even use gofmt to export variables that you want exported throughout the project. I wrote about it on this coderwall: https://coderwall.com/p/ds3iuw
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.