
Linux kernel coding style - Jerry2
https://www.kernel.org/doc/html/v4.10/process/coding-style.html
======
quotemstr
This coding style works, sure. But so does the NT kernel style, which is the
opposite of Linux kernel style in many ways. For example, in NT, all structs
and pointers are typedefs. So what? There's a certain elegance to type names
being one token long.

People bikeshed source code formatting. They make arguments about developer
portability and visual minutiae, usually without any sort of evidence, when in
reality the higher-level organization of the code matters a lot more.
Optimizing code for readability quickly runs into diminishing returns and
begins hurting a lot more than it helps.

In general, I'm strongly against rules and ceremony and centralization when it
comes to coding. Ostensibly, it's all about hygiene and best practices and
whatever, but in practice this kind of discipline amounts to "I like it this
way and you're going to like it too". It's far more important to let
developers make decentralized, rapid decisions about the best approach for a
particular task than to enforce some kind of useless Procrustean uniformity on
everyone.

~~~
remline
The two styles work because they are not being mixed with their opposite. A
cached shed optimization is what makes working with others bearable.

~~~
Analemma_
That’s sort of what the parent is saying: “the only code formatting rule that
matters is consistency, everything else is bollocks”. But people want to think
there’s some kind of higher justification for their preferred style, so they
come with these just-so stories that don’t have any real evidence behind them.

~~~
greggman
The word consistent is an issue in and of itself. You probably mean you think
it's best when a style is applied consistently. But probably don't care that
the style itself values consistency. The style linked above is not remotely
consistent. Braces in different columns. Braces styles for functions different
from non functions. if statement can have or into have braces. All extremely
inconsistent

~~~
quotemstr
ITYM "regular", not "consistent".

------
dimman
I think these guidelines are something every C programmer should atleast have
read and reflected about.

I've been coding according to these guidelines for quite a while with some
minor modifications:

Always use curly braces (especially when you're not alone coding in the
codebase as it allows for easy modification without code ending up out of the
intented scope).

80 char width; well I don't follow this one as I really do prefer long lines
over broken lines for readability.

Other than that I think these guidelines are great and offer consistency and
easy to read code, in my opinion.

~~~
nerdponx
80 char width helps encourage you to "do less stuff in each line", rather than
"break lines at 80 chars".

But I agree, after a few levels of indentation (which is sometimes
unavoidable) you end up struggling.

~~~
dingo_bat
Also, when a function takes five arguments, and each_argument_looks_like_this,
it's easy to hit 80 chars!

~~~
quickben
Maybe pass them in a struct?

~~~
disconnected
The linux kernel USB API has a few functions that take a bunch of arguments.
For example:

int usb_control_msg(struct usb_device __* dev, unsigned int pipe, __u8
request, __u8 requesttype, __u16 value, __u16 index, void __* data, __u16
size, int timeout);

So it is kind of hard to avoid going over the limit.

What we end up doing is break each argument into one line, like this (I hope
the formatting comes out all right):

int res = usb_control_msg(

    
    
        dev,
    
        usb_sndctrlpipe(dev, 0),
    
        0x41,
    
        ...
    

);

It's not so much of an eye-sore.

~~~
quickben
Ahhhh I see. Nortel had that coding guideline actually. Just in their case,
the first argument followed the parenthesis. The second argument (and the
rest) followed the first argument column.

------
rawoke083600
I always "preach" the value is in uniformity ! Weather you camelCase or kebab-
style or using my-super-foo-style as long as everyone on the team uses the
SAME style. Thats a WIN ! THATS where the value is !! Not in the RIGHT style
but in the SAME style.

~~~
krylon
Amen to that! I have my preferences on where I place my curly braces, and I
have strong opinions on camelCasing versus using_underscores. But for a given
code base, consistency outweighs any advantages any given coding style might
have.

Also, emacs has glasses-mode, so when I have to work on a code base that uses
camel case, at least I don't have to squint really hard. ;-)

------
Unknoob
> Inconsistently using braces for function declarations.

> Not using braces for conditions followed by single line statements.

> Using abbreviations.

This is enough for me to say fuck this guide.

------
2bluesc
I tend to follow these guidelines with the following exceptions:

1\. always use curly braces

2\. 4 spaces instead of a tab character

~~~
wvenable
I violate #1 in only one case, the entire statement has to be one line:

    
    
        if (var1 != var2) return false;
    

But having it on two lines and tabbed out without braces seems extremely ugly
and dangerous to me.

~~~
luckydude
100% agree with both points. Though I'm the crazy guy who does

    
    
        #define unless (x) if (!(x))
    

so I can do

    
    
        unless (f = popen("ps -axf")) die("popen of ps -axf");

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

This refers to systems hungarian, the brain-dead twin of apps hungarian. The
latter can be useful in C.

~~~
quotemstr
"Apps Hungarian" is what happens naturally when defining meaningful variable
names. You don't need to systematize it.

~~~
greggman
There are advantsges to systematizing it.

[https://www.joelonsoftware.com/2005/05/11/making-wrong-
code-...](https://www.joelonsoftware.com/2005/05/11/making-wrong-code-look-
wrong/)

------
Sir_Cmpwn
The biggest take-away from this, in my opinion, is that it's better to just
type `struct foobar` instead of typedefing `foobar_t`. Structs should be
treated differently than scalars, and therefore you should write them
differently. The #1 principle of any coding style should be to optimize for
readability and clarity over writability and convenience.

Also, please limit your lines to 80 characters.
[https://sr.ht/toyc.jpg](https://sr.ht/toyc.jpg)

~~~
nitrogen
> 80 characters

Assuming indentation is counted against those 80, why not use a bigger
monitor?

~~~
Sir_Cmpwn
Did you see my link?

More practically, a lot of people (myself including) will split their monitor
vertically to consider lots of code at once, and talk about code in emails via
patches on mailing lists and such where 80 columns is the norm.

------
etqwzutewzu
"It’s a mistake to use typedef for structures and pointers."

C programmers tend to forget this wise recommendation.

~~~
Ace17
I have always though it was good practise (because it reduces the verbosity) ;
Could you please prove me wrong? :-)

~~~
dllthomas
It varies a bit by context; Linus's call is likely the right one in the
context of the kernel, though to be sure it's not so big a deal that other
approaches can't be made to work fine.

You call out one upside - decreased verbosity. The accompanying downside is
usually - as in this case, for both structs and pointers - that potentially
relevant information is made less visible. Whether it's a good idea depends on
how likely that information is to be _actually_ relevant, weighed against the
upsides.

Where performance is relevant, you want to be aware of where you're
potentially passing large structs around. Putting this info in the type name
instead is an option (eg _s), and can reduce verbosity a bit. I don't know of
any good reasons to call out structs that are sized like primitives.

The case against hiding pointers is much stronger. Level of indirection can be
relevant to performance, and is _often_ relevant to correctness, particularly
where mutation is involved. You can put it in the type name, but it's not
going to be any less verbose - a star is already one character. I allow a
possible exception here for where an opaque type is allocated by a library and
passed around as a handle and the client really doesn't need to ever know
whether it's a pointer or an int index or what.

------
no_cake
In case anyone is wondering if there's some kind of linter for these rules,
you can use checkpath.pl
[https://github.com/torvalds/linux/blob/master/scripts/checkp...](https://github.com/torvalds/linux/blob/master/scripts/checkpatch.pl)

------
dingo_bat
The article has sentences like:

> First off, I’d suggest printing out a copy of the GNU coding standards...

Which suggests this was written from the point of view of a specific person.
In which case, it should attribute the author somewhere. I couldn't find a
byline anywhere. Also, no date.

~~~
antientropic
It was originally written by Linus and is quite old (the line about burning
the GNU coding standards was there in the first Git import [1], but IIRC it's
way older).

[1]
[https://github.com/torvalds/linux/blame/master/Documentation...](https://github.com/torvalds/linux/blame/master/Documentation/process/coding-
style.rst)

~~~
antientropic
Looks like it was introduced in Linux 1.3.53, which is from Jan 1996.
[http://lxr.linux.no/#linux-
old+v1.3.53/Documentation/CodingS...](http://lxr.linux.no/#linux-
old+v1.3.53/Documentation/CodingStyle)

------
have_faith
Are there any languages where code-style is required to be a certain way? or
it won't compile. I mean full authoritarian about everything, not just based
around white-space like python.

~~~
Athas
Yes, old fixed-format languages like FORTRAN and RPG (the older versions).
Everything had to be written in specific columns, due to their punched card
heritage.

~~~
mmarx
Fixed-format FORTRAN isn't actually that rigid. The first six columns have
special semantics, but apart from that, the compiler is not going to enforce a
certain style.

------
chimprich
> A C programmer would call that variable tmp, which is much easier to write,
> and not the least more difficult to understand.

Yuck. Abbreviations are usually bad. For one thing, people tend to pick
different ways to abbreviate things so an hour later when you're trying to
grep for where the variable was used you have to try to remember whether the
variable was written tmp, temp, or temporary.

In this example, "temporary" is probably the least useful thing to know about
the variable, since most variables are temporary. How about "counter"?

~~~
quotemstr
Short idioms are essential for concision in specific domains though.

My favorite example: I was writing some graphics code recently, and some
reviewer said: "I don't understand this uv abbreviation that appears all over
the code. Please expand it."

headdesk.gif

(For those who aren't familiar: u and v are conventional names of texture
coordinates, like x, y, and z are conventional names of spatial coordinates.
There's no abbreviation to expand.)

~~~
javajosh
I am sure you are right, but I can't figure out what "xy" would mean in a
program, either. Perhaps all the points on a plane normal to z?

~~~
krylon
I used to use x and y as my generic loop iteration variables until I worked on
code that involved two-dimensional coordinates, and suddenly x and y had very
specific meaning.

I skipped to i and j, but I am certain there are mathematicians out there who
find that confusing, too.

I guess, it's about context, too, at least a little.

~~~
lomnakkus
> I skipped to i and j, but I am certain there are mathematicians out there
> who find that confusing, too.

IME it's pretty standard in most of mathematics to use "i" and "j" as index
variables when e.g. doing sums and products over indices/sets. (Though I
suppose you could be talking about the use of i, j, k as axes?)

~~~
krylon
I think in Quaternions, i, j, and k are the non-real components.

~~~
lomnakkus
Good point, I'd missed that one! :)

What does one for index variables in that notation? Or is the main point of q
notation that you don't need index variables? ;)

------
mydeardiary
It would be nice to have this integrated into clang-format.

~~~
alexeiz
It doesn't have to be integrated. It shouldn't be hard to produce a .clang-
format configuration file for this coding style.

------
calafrax
> if you need more than 3 levels of indentation, you’re screwed anyway, and
> should fix your program.

I hope some JS programmers read this

~~~
nerdponx
Why are anonymous functions so popular in JS? Why not just name the callback?

~~~
quotemstr
Because Java is a kingdom of nouns, and for the most part (method handles,
which are just fancy reflection objects, aside), you can't name a function
without creating a closure.

Anonymous callback:

    
    
      Foo.foo(() -> bar());
    

Named callback:

    
    
      private final class MyFooDelegate implements FooDelegate {
        @Override
        public void doFoo() {
          bar();
        }
      }
    
      ...
    
      Foo.foo(new MyFooDelegate())

~~~
pjmlp
You forgotten about method handles.

