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

51–60 of 102 posts

Re: Linux kernel coding style

#51

Post by notacoward »

raverbashing wrote: post #39
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…

"Such advice for the kernel is even hypocritical, when that code uses size_t and off_t and many others quite liberally" Did you even read their explanation. Apparently not. This is an acceptable use of typedefs, as explained there, exactly because a size_t varies between architectures.

That's just rationalization. It's basically saying that some typedefs are OK because Linus is used to them, but he doesn't want to take the few seconds to figure out any new ones. The cases for typedefs shouldn't be treated as exceptions. The cases against them should.

Re: Linux kernel coding style

#52

Post by maguirre »

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…

I agree with you. I think structs help readability specially we using function pointers within structures. Would it be out of line to suggest a new naming convention for struct typedefs and pointer typedefs i.e _t for typedegs and _tp for typedeg pointers

Re: Linux kernel coding style

#53

Post by cesarb »

robin_reala wrote: post #43
andmarios wrote: post #23

Earlier quoted context omitted.

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

That "initial commit" was the import of the whole kernel tree into git, ignoring any previous history; that commit having been made by Linus does not mean any particular file was written by Linus.

You should instead look into historical repositories like https://archive.org/details/git-history-of-linux, which go further back; however, before Bitkeeper the authorship of each change was not tracked in detail (that historical repository IIRC does not have the detailed Bitkeeper history, but there is another repository somewhere which has it).

Re: Linux kernel coding style

#54

Post by qznc »

dezgeg wrote: post #37
maxlybbert wrote: post #31

Earlier quoted context omitted.

Or lindent, which I think is mentioned in the kernel style guide (it's a shell script that calls indent with set parameters).

Sadly, running Lindent on almost any existing source file in the tree will produce dozens of spurious diff hunks due to most other people manually formatting their code, so Lindent is quite useless in practice. It really does bother me how much of the coders' and code reviewers' bandwidth in the kernel community is wasted due to these silly formatting issues. In most IDE-using communities these problems were solved a…

Linus could easily do "lindent reformat" commit every once in a while or even automate it. It seems they do not care that much for the styleguide?

Re: Linux kernel coding style

#55

Post by raverbashing »

notacoward wrote: post #51
raverbashing wrote: post #39

Earlier quoted context omitted.

"Such advice for the kernel is even hypocritical, when that code uses size_t and off_t and many others quite liberally" Did you even read their explanation. Apparently not. This is an acceptable use of typedefs, as explained there, exactly because a size_t varies between architectures.

That's just rationalization. It's basically saying that some typedefs are OK because Linus is used to them, but he doesn't want to take the few seconds to figure out any new ones. The cases for typedefs shouldn't be treated as exceptions. The cases against them should.

"some typedefs are OK because Linus is used to them, but he doesn't want to take the few seconds to figure out any new ones."

NO

Because the wrong uses are more numerous than the right ones. It's that simple

Creating typedefs for integers is mostly useless and causes confusion, except in the cases specified.

Of course, if you work with a small project it's easier than with a big project like the kernel.

And of course I admire Linus for cutting through BS and usually avoiding it.

Re: Linux kernel coding style

#56

Post by thatswrong0 »

> Do not unnecessarily use braces where a single statement will do.

    if (condition)
	    action();
> and

    if (condition)
	    do_this();
    else
	    do_that();
The Apple SSL bug (https://nakedsecurity.sophos.com/2014/02/24/anatomy-of-a-got...) makes me wonder if this is really worth the potential for introducing bugs.

Re: Linux kernel coding style

#57

Post by adestefan »

maguirre wrote: post #52
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…

I agree with you. I think structs help readability specially we using function pointers within structures. Would it be out of line to suggest a new naming convention for struct typedefs and pointer typedefs i.e _t for typedegs and _tp for typedeg pointers

The argument is that you don't need to resort to naming conventions since the language already supports differentiating them with the struct and the * markings. It's one of the things I fully support. I hate working on code with a billion typedefs for every struct.

Re: Linux kernel coding style

#58

Post by adestefan »

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 emacs does it for me automatically.

Re: Linux kernel coding style

#59

Post by adestefan »

qznc wrote: post #54
dezgeg wrote: post #37

Earlier quoted context omitted.

Sadly, running Lindent on almost any existing source file in the tree will produce dozens of spurious diff hunks due to most other people manually formatting their code, so Lindent is quite useless in practice. It really does bother me how much of the coders' and code reviewers' bandwidth in the kernel community is wasted due to these silly formatting issues. In most IDE-using communities these problems were solved a…

Linus could easily do "lindent reformat" commit every once in a while or even automate it. It seems they do not care that much for the styleguide?

Linus shuns commits that do nothing by reformat code. However, if you go in and make a change, then you'll probably get marked down by the maintainer if you don't fix up the formatting at that time.

Re: Linux kernel coding style

#60

Post by DSMan195276 »

thatswrong0 wrote: post #56

> Do not unnecessarily use braces where a single statement will do. if (condition) action(); > and if (condition) do_this(); else do_that(); The Apple SSL bug ( https://nakedsecurity.sophos.com/2014/02/24/anatomy-of-a-got... ) makes me wonder if this is really worth the potential for introducing bugs.

IMO, the bug was a much deeper issue then simply not putting braces on if statements. It doesn't matter if the code becomes this:

    if (condition) {
        goto fail;
    }
        goto fail;
if nobody looks at the commit. Don't get me wrong though, braces on if's do help for making cleaner patches, so there is a valid reason to request braces. You should never rely on them to fix these types of bugs though, that's bound to come back and bite you. In general, having a proper system for submitting and approving patches (Like the Kernel has) will allow you to avoid errors like this one.
Post reply on HN