Linux kernel coding style

Other people are complaining about the 80 character line limit, but personally, I&#x27;m shocked and dismayed by the preference for no braces on `if` statements with single line blocks. It is <i>so</i> easy to accidentally add a line to what looks like an `if` block (but isn&#x27;t since there are no braces), and then you have a bug that is visually very difficult to spot. I&#x27;m pretty strongly against this rule!

2017 and contributors still need to discuss about coding style =&#x2F;<p>If you want to enforce codding style (which is OK) you need to provide developers the tools to ease that process.<p>Contributing with patches to 15 different projects, using 15 different rules for styling makes it impossible to keep up.<p>FOSS projects should start using tools like clang-format so developers don&#x27;t need care if a project use 2&#x2F;4&#x2F;6&#x2F;8 spaces instead of tab. The tool should be able to automatically format the code before committing.<p>Some projects even use git hooks to compare the commit with auto-generated styling tools to check if it follows the rules.

Only thing I really don&#x27;t agree with is the 80 char max.<p>I&#x27;m not suggesting unlimited but isn&#x27;t it time we revisit this?<p>It really feels like one of those &quot;we&#x27;ve always done it this way so just leave it&quot;

Indentation war is ON again ;-)<p>TL;DR - Linux kernel source code use TABs (8 characters) instead of spaces. The rationale behind is that the maintainers believe that large indentation makes code easier to read on screen (especially for long hours), makes sense.<p>Personally I (not a programmer but Linux SysAdmin&#x2F;Ops&#x2F;Infra Architect background) tend to use 4 spaces everywhere else (e.g. Shell, Ruby, Java and all sorts of configuration files). Not to pick a fight (sounds familiar? ;-) but 2 spaces in general make readability worse.<p>Anyway, the most important point is to honour what is already established&#x2F;in place and stick to it, whatever you work on.

Have to agree with the comment on GNU coding style, I work on a project that uses it and it really sucks. Braces on a newline and indented two spaces...

Offtopic question, what documentation tool is used for this? I&#x27;ve seen it a lot of times but I&#x27;m not sure how to search for it. Thanks!

It seems like sensible advice but with gratuitous insults interspersed, just to make sure you&#x27;re really clear that the natives are not friendly.

The writing style of this document seems somewhat casual (&quot;Please at least consider the points made here.&quot;) and a little confusing compared to OpenBSD&#x27;s style guide. [1]<p>The LibreSSL team spent months putting the OpenSSL code into KNF. It makes a big difference, even though it may seem trivial.<p>[1] <a href="http:&#x2F;&#x2F;man.openbsd.org&#x2F;style" rel="nofollow">http:&#x2F;&#x2F;man.openbsd.org&#x2F;style</a>

This is from Documentation&#x2F;process&#x2F;coding-style.rst (formerly Documentation&#x2F;CodingStyle) in the kernel source tree; an unrendered version is canonically at <a href="https:&#x2F;&#x2F;www.kernel.org&#x2F;doc&#x2F;Documentation&#x2F;process&#x2F;coding-style.rst" rel="nofollow">https:&#x2F;&#x2F;www.kernel.org&#x2F;doc&#x2F;Documentation&#x2F;process&#x2F;coding-styl...</a>

What is K&amp;R? It&#x27;s referenced several times but not defined.

&gt;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>Should I be aware of something from GNU coding standards?

&gt; Tabs are 8 characters...<p>The madman!<p>&#x2F;s<p>Actually, now that I think about it, he has a point. Having a little more horizontal space seems like it would be easier on the eyes.

I like gofmt which avoids this problem in golang.

Coding style wars will die with the rise of *fmt.