Only one of the programming jobs I have had used a coding standard. Their standard, created in-house, is more or less the standard I follow today. It includes things like:
- Prefix global variables with g_
- Prefix static variables with s_ (for local statics) or S_ (for global statics)
It also required the use of braces, which I have blogged about before, even in single-line instances such as:
if (fault == true)
{
BlinkScaryRedLight();
}Many of these took me a bit to get used to because they are different than how I do things. Long after that job, I have adopted many/most of that standard in my own personal style due to accepting the logic behind it.
I thought I’d ask here: Are there any good “widely accepted” C coding standards out there you would recommend? Adopting something widely used might make code easier for a new hire to adapt to, versus “now I have to learn yet another way to format my braces and name my variables.”
Comments appreciated.
Are there any good “widely accepted” C coding standards out there I would recommend? Nope. None of them match my style exactly, and if I wanted to blindly follow a style, I’d join a cult. Even at my last job, I pretty much used my style. It wasn’t that much of an issue, since it was very close to the style the original developer used, and other developers who joined later didn’t care.
I have often been the sole developer at small companies, so it didn’t really matter, but I’d like to create a standard for future developers so the code doesn’t look so schizophrenic from one file (or function!) to the next.
There are some unwieldy things I picked up at a previous job, and I like them in spirit, but they get annoying in practice. Like, having just ONE return from a function does make it much easier to understand… it can only exit there! But then when there are NULL checks and call something and check that then so on, it makes a web of nested curly braces. I’d sure like to see how that is handled in the wild. I think the whole Clean Code movement just says if you have more than X lines, it has to be broken up. And that’s not something I have been able to do since most of the problems are when it’s calling other functions… open, if good, then write, then if good, then …
I learned about “semantic versioning” and assume there are other cults … er, styles, for C code out there.
Early returns. In C, you can always return at any point in a function. For example, the function here:
https://github.com/spc476/mod_blog/blob/07b1833b8d002519b9940ec273189bcf9c8c97ec/src/blog.c#L247
I hate thinking about what it would look like with one return.
The “Clean Code” movement has good intentions, but very bad advice. I hate their “break up functions longer than X lines” (where X tends to be around 20) because naming things is one of the two hardest problems in Computer Science (the other being cache invalidation and off-by-one errors). Just one exit point? I don’t recall that being from the Clean Code Cabal, but from Pascal, which didn’t allow early returns.
As for semantic versioning, I found that it tends to work more for library code. I try to follow it myself for libraries and modules, but it can be hard to know if a bug fix is a “breaking change” or not for other people. For applications, just a incrementing number is good, if you even need it.
For C? There are so many coding standards and layout styles for C that creating a new one just adds to the confusion. (Insert obligatory xkcd standards strip reference here.) Look at all the dozens of options on the “indent” program.
Pick one standard for your company or your project, stick with it, and document it. Write or get whatever tools exist for your editors or IDEs that enforce it. Reject change submissions that reformat code
Relatively modern languages often come with programs that enforce coding style, e.g. “go fmt” for golang. Too bad programming language designers didn’t notice that BASIC09 had that over forty years ago.