I doubt everyone agrees to that coding style, I certainly don't. However when submitting code to a project I'd still stick to the prescribed coding style, because I believe consistency in any code base can be just as important as any other measure of readability.
Mostly good advice, sometimes even great, but the part about typedefs is total BS. Any non-trivial program will use values that have clearly different meanings but end up being the same C integer type. One's an index, one's a length, one's a repeat count, one's an enumerated value ("enum" was added to the language to support this very usage), and so on. It's stupid that C compilers don't distinguish between any two types that are the same width and signedness; why compound that stupidity? Both humans and static analyzers could tell the difference if you used typedefs, and avoid quite a few bugs as a result. Being able to change one type easily might also make some future maintainer's life much better. There's practically no downside except for having to look up the type in some situations (to see what printf format specifier to use), but that's a trivial problem compared to those that can result from <i>not</i> using a typedef.<p>Don't want to use typedefs? I think that's a missed opportunity, but OK. Don't use them. OTOH, anyone who tries to pretend that the bad outweighs the good, or discourage <i>others</i> from using them, is an ass. Such advice for the kernel is even hypocritical, when that code uses size_t and off_t and many others quite liberally.
"First off, I'd suggest printing out a copy of the GNU coding standards,
and NOT read it. Burn them, it's a great symbolic gesture."<p>Shots fired.
I am glad that for Go there is `go fmt` which predefines some of the issues mentioned in the article. Thus there is "one global coding style for Go". It's another matter if one likes it or not.
"Get a decent editor and don't leave whitespace at the end of lines."<p>Trailing whitespace always raises a huge red flag for me whenever I look at someone's code. It's not just sloppy, it often makes diff output so noisy you can't detect real changes to the code.
>Encoding the type of a function into the name (so-called Hungarian notation) is brain damaged - the compiler knows the types anyway and can check those, and it only confuses the programmer. No wonder MicroSoft makes buggy programs.<p>"Making Wrong Code Look Wrong" by Joel Spolsky is a must-read and contains an explanation of Apps Hungarian (the original, thoughtful one) vs Systems Hungarian
<a href="http://www.joelonsoftware.com/articles/Wrong.html" rel="nofollow">http://www.joelonsoftware.com/articles/Wrong.html</a>
"There are heretic movements that try to make indentations 4 (or even 2!)
characters deep, and that is akin to trying to define the value of PI to
be 3."<p>HA!
> <i>spaces are never used for indentation</i><p>If indentation should always use tabs (0x09) and never spaces (0x20), then the whole rant about indentation width is pointless. Any modern editor will allow you to adjust the displayed width of a tab. It's only when you use spaces for indentation that the width becomes a concern.
I like it<p>I really prefer using tabs. Having it displayed as 8 spaces in other languages is not as good as in C<p>And they get it right about typedefs in C
It's a very nice coding style. It keeps the code in pieces that are easy to grasp as units, it doesn't waste space and doesn't clutter the code at the same time.<p>Just take any random function from the kernel sources and ask yourself, what does it do. I think in most cases you'll find it's really obvious...<p>For me I find the kernel sources one of the most readable and understandable sources I've seen. The structure of them is just so clearly visible from the sources. I think a lot of that has to do with the coding style.
I'm a fan of the Tcl/Apache/BSD style. Indeed, Tcl has nice C code:<p><a href="https://github.com/tcltk/tcl/blob/master/generic/tclCompile.c" rel="nofollow">https://github.com/tcltk/tcl/blob/master/generic/tclCompile....</a>
> Do not unnecessarily use braces where a single statement will do.<p><pre><code> if (condition)
action();
</code></pre>
> and<p><pre><code> if (condition)
do_this();
else
do_that();
</code></pre>
The Apple SSL bug (<a href="https://nakedsecurity.sophos.com/2014/02/24/anatomy-of-a-goto-fail-apples-ssl-bug-explained-plus-an-unofficial-patch/" rel="nofollow">https://nakedsecurity.sophos.com/2014/02/24/anatomy-of-a-got...</a>) makes me wonder if this is really worth the potential for introducing bugs.
I agree with and already practice many of these conventions (at least the ones that apply to C-like languages in general). It's interesting that I do and I kind of wonder what lead me down that path, since I haven't programmed in C since my college days. I often think that my assembly class from those days pushed me into making my code as vertical as possible rather than the indented-if-statement-curly-brace hell that I often see, since assembly was very readable without having that capability.