Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux kernel coding style

kernel.org

Post reply on HN
Print view View original

41–50 of 102 posts

Re: Linux kernel coding style

#41

Post by eyko »

bryal wrote: post #10
robinhoodexe wrote: post #4

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

With the target being the, what?, 5 people?, that enjoy following the GNU coding standards.

The Kernel coding style wasn't written a week ago. The first I read it, more than a decade ago, the GNU coding standards did matter and I remember feeling quite hurt by that (in a good way, since I don't think anybody took it that seriously).

Matter of fact, the GNU coding standards still matter (to a certain extent) to many of us, and you would be thankful that they did, since it's the basis that provides consistency among GNU (and non GNU) command line apps, for example.

The GNU coding standards is an extensive document which doesn't only talk about how to write C code, but also how to talks about how to design software consistent with the GNU principles (command line user interfaces, options, stdin/stdout behaviour, etc).

Personally I take the kernel coding style as a whole different thing. It's a short guide on how to write consistent code for the linux kernel. And full of good opinionated choices in my opinion. Its scope is very different from that of the GNU coding standards (which, I'd say, is focused towards writing userland programs which the user will interact with).

Also, remember that GNU wanted (wants?) to create an OS, not just a kernel, so I guess we can read their guidelines as something similar to Apple's human interface guidelines for devs :)

Re: Linux kernel coding style

#42

Post by Zardoz84 »

coldpie wrote: post #40
scrollaway wrote: post #30

Earlier quoted context omitted.

I got into that fight so many times. It baffles me a majority of programmers out there do not understand that tabs are not just a matter of preference, they are a matter of accessibility . I read better on 4-char indent, and some people read better on 8-char indent. Let the user choose, rather than force it with spaces.

I don't care much either way so long as you NEVER VERTICALLY-ALIGN YOUR LINES. int valueone = 1; int anothervalue = 2; float yetmore = 3.; Aggggh what a waste of time why do people do this

but looks nice....

Re: Linux kernel coding style

#43

Post by robin_reala »

andmarios wrote: post #23
snlacks wrote: post #6

Earlier quoted context omitted.

I find it hard to agree with a lot of this, but it'd obviously be someone who's written a lot of code, thought a lot about how to write code, and reads a lot of code - even if we didn't know who it was. There's a lot to learn from reading stuff like this, if you take it all with a grain of salt... or if you're contributing.

I think it was written by Torvalds and other kernel hackers. It is part of the Linux source code, under the Documentation directory.

Initial commit was by Linus[0], but it looks like most of the other commits[1] have been small amends by other people (apart from a couple of new chapters)

[0] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....

[1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....

Re: Linux kernel coding style

#44

Post by edent »

coldpie wrote: post #40
scrollaway wrote: post #30

Earlier quoted context omitted.

I got into that fight so many times. It baffles me a majority of programmers out there do not understand that tabs are not just a matter of preference, they are a matter of accessibility . I read better on 4-char indent, and some people read better on 8-char indent. Let the user choose, rather than force it with spaces.

I don't care much either way so long as you NEVER VERTICALLY-ALIGN YOUR LINES. int valueone = 1; int anothervalue = 2; float yetmore = 3.; Aggggh what a waste of time why do people do this

Because I find it really handy to quickly, and visually, check the sanity / logic of something.

In your example, it's really easy to run your eyes down a column and see that one of those values is radically different from the others.

As a trivial example:

    int robert_age = 32;
    int annalouise_age = 25;
    int bob_age = 250;
    int dorothy_age = 56;
I find easier to read as:

    int robert_age     = 32;
    int annalouise_age = 25;
    int bob_age        = 250;
    int dorothy_age    = 56;
Coding styles are about readability and usability. The columns metaphor works well for some categories of data - that's why spreadsheets are so popular.

Re: Linux kernel coding style

#45

Post by bluecalm »

coldpie wrote: post #36
bluecalm wrote: post #34

Earlier quoted context omitted.

As a recreational C programmer I have the same impression. I've always used typedefs for structs and enums in my code and I think it makes it more readable and easier to work on. My reaction to reading the kernel style guidelines was a surprise and I am happy I am not the only one disagreeing.

As a "professional" C/C++ programmer (day job), I don't have strong feelings either way. It is frustrating not knowing what the type of a variable is. Am I being passed a pointer, or an integer, or a floating point value, or a whole struct, or what? This really matters! Digging up the definition isn't difficult, but isn't easy, either. I would lean against using typedefs liberally, but I don't feel strongly about it.…

Right, I imagine it's completely different in a project a lot of people are contributing to and 1-2 people thing where I am familiar with the whole codebase and define the typedefs myself.

Re: Linux kernel coding style

#46

Post by cesarb »

andmarios wrote: post #23
snlacks wrote: post #6

Earlier quoted context omitted.

I find it hard to agree with a lot of this, but it'd obviously be someone who's written a lot of code, thought a lot about how to write code, and reads a lot of code - even if we didn't know who it was. There's a lot to learn from reading stuff like this, if you take it all with a grain of salt... or if you're contributing.

I think it was written by Torvalds and other kernel hackers. It is part of the Linux source code, under the Documentation directory.

If I recall correctly, it was written by Linus Torvalds a long time ago. I haven't found yet when it originally appeared, but it was probably the pre-Bitkeeper days; I found a discussion about it dated from the last century.

There were many edits to it, by several people; its more recent story can be seen on the kernel git repository. Of course, if Linus disagreed with an edit, it wouldn't go in, so in a way it's still his document.

Re: Linux kernel coding style

#47

Post by notacoward »

cesarb wrote: post #38
notacoward wrote: post #25

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 t…

Most of that section is concerned with hiding structs or pointers as typedefs: "In general, a pointer, or a struct that has elements that can reasonably be directly accessed should _never_ be a typedef." Say you are reading a function, and see a local variable declared: "something_t variable_name;". Is it a struct, a pointer, or a basic type? Now compare with "struct something * variable_name;", which is clearly a po…

> it's item (c): "when you use sparse to literally create a > _new_ type for type-checking."

The problem is that this is presented as an exception that must be (strongly) justified. I think that using typedefs for integer types should be acceptable by default, and there should be specific rules for when to avoid them. The burden of proof is being put on the wrong side.

Even for structs, the argument for typedefs is stronger than the argument against. Even across a purely internal API, the caller often doesn't need to know whether something is an integer, a pointer to a struct, a pointer to a union, a pointer to another pointer, or whatever. Therefore they shouldn't need to know in order to write a declaration, which will become stale and need to be changed if the API ever changes. This is basic information hiding, as known since the 60s. Exposing too much reduces modularity and future flexibility. I've been working on kernels for longer than Linus, and the principle still applies there.

Again, it comes down to defaults and burden of proof. The rule should be to forego struct typedefs only if every user provably needs to know that it's a struct and what's in it (which is often a sign of a bad API). Even then, adding a typedef hardly hurts; anyone who needs to know that a "foo_t" is a "struct foo" and can't figure it out in seconds shouldn't be programming in the kernel or anywhere else.

Re: Linux kernel coding style

#48

Post by DSMan195276 »

notacoward wrote: post #25

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 t…

You're not understanding their idea behind typedef. IMO, their lines for usage are extremely good when adhered too.

The note about integers is worth complaining a bit about, I agree there is merit to typedef'ing integers in some situations, but the Kernel standard agrees with that in those instances (And the example is bad, there are instances of 'flag' typedefs in the kernel). In general the note about integers is just to discourage spamming typedef's everywhere.

More importantly then integers though, their note about making opaque objects with a typedef is extremely good practice, as it makes it easy to distinguish when it is or isn't expected that you'll be accessing the members directly.

The point of those rules are to allow typedef to actually be useful and communicate some information. If you just allow typedef'ing everything in every situation, then whether or not something is typedef'd becomes useless information to the reader.

Re: Linux kernel coding style

#49

Post by chj »

coldpie wrote: post #40
scrollaway wrote: post #30

Earlier quoted context omitted.

I got into that fight so many times. It baffles me a majority of programmers out there do not understand that tabs are not just a matter of preference, they are a matter of accessibility . I read better on 4-char indent, and some people read better on 8-char indent. Let the user choose, rather than force it with spaces.

I don't care much either way so long as you NEVER VERTICALLY-ALIGN YOUR LINES. int valueone = 1; int anothervalue = 2; float yetmore = 3.; Aggggh what a waste of time why do people do this

People waste a lot of time in making things pleasant to look at.

Re: Linux kernel coding style

#50

Post by jackalope »

"Get a decent editor and don't leave whitespace at the end of lines."

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.

Post reply on HN