5 ms·

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 a

by simias 13y ago

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.

pjmlp 13y ago
Easy, integrate indent in the source control checkin hooks. No more arguing.
- simias 13y ago
  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.
  - pjmlp 13y ago
    It is a standard for the specific project. Just a decision, like many other, that take place at the beginning of a project.
- RogerL 13y ago
  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" ;))
  - pjmlp 13y ago
    I took part in consulting projects that decided on the style guide as the project infrastructure was designed. It only applied to the source code for the project at hand.
DSMan195276 13y ago
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.
sbi 13y ago
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. [1]: http://clang.llvm.org/docs/ClangFormat.html http://clang.llvm.org/docs/ClangFormat.html
bradleyjg 13y ago
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."
- thezilch 13y ago
  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.
  - bradleyjg 13y ago
    How would the c equivalent of fmt layout duff's device, and would it be clearer or less clear than Tom Duff's original formatting (http://www.lysator.liu.se/c/duffs-device.html http://www.lysator.liu.se/c/duffs-device.html)?

by simias 13y ago

pjmlp 13y ago

Easy, integrate indent in the source control checkin hooks. No more arguing.

simias 13y ago
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.
- pjmlp 13y ago
  It is a standard for the specific project. Just a decision, like many other, that take place at the beginning of a project.
RogerL 13y ago
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" ;))
- pjmlp 13y ago
  I took part in consulting projects that decided on the style guide as the project infrastructure was designed. It only applied to the source code for the project at hand.

DSMan195276 13y ago

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.

sbi 13y ago

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. [1]: http://clang.llvm.org/docs/ClangFormat.html http://clang.llvm.org/docs/ClangFormat.html

bradleyjg 13y ago

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."

thezilch 13y ago
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.
- bradleyjg 13y ago
  How would the c equivalent of fmt layout duff's device, and would it be clearer or less clear than Tom Duff's original formatting (http://www.lysator.liu.se/c/duffs-device.html http://www.lysator.liu.se/c/duffs-device.html)?