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

61–70 of 102 posts

Re: Linux kernel coding style

#61

Post by juliangregorian »

humanrebar wrote: post #35
JBiserkov wrote: post #11

>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. "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 http://www.joelonsoftware.c…

C is not a strongly typed language and it does not allow function overloading. C projects should allow for some flexibility in naming notations to make up for those language design decisions. Also, any project that uses int return codes shouldn't be leaning too heavily on type safety.

This is really interesting. I was about to correct you since I remembered using function overloading, but then I double checked and it was indeed C++. I knew about C++'s name mangling from having coded against it in FFI, but never knew why it existed: the name mangling is what allows C++ to have function overloading. Light bulb!

Re: Linux kernel coding style

#62

Post by notacoward »

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

While I generally think typedefs for integer/enumerated types and structs/unions are a good idea, I also don't think the arguments I've made apply as much to typedefs for pointers. The difference between an X and a pointer/reference to X is often an explicit part of the contract between modules or functions. If that contract ever changes, the declarations and usage should change in ways beyond replacement of an identifier. That's different than if X itself changes, which usually can and should be transparent. You also get the same type checking for an "X pointer" declaration (avoiding star because of HN mis-formatting issues) as for its "X_ptr" equivalent. Even compilers will flag "pointer to wrong type" errors, even as they remain oblivious to many "wrong integer type" errors. In short, "X_ptr" typedefs don't help anywhere that "X" typedefs don't already.

I'm not going to argue against pointer typedefs, though I personally don't use them. I'm just saying that I can't make a strong argument for them as I believe I can for other cases.

Re: Linux kernel coding style

#63

Post by DSMan195276 »

Dewie wrote: post #12
patrickg wrote: post #7

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.

I don't see why there couldn't be a `kernel fmt` tool. In this day and age, we should really be beyond having to worry about things like hmm, what was the brace style in this project again, and should all if/while/for have mandatory braces? .

The kernel has a perl script called 'checkpatch.pl'[0] which can check if code is formatted correctly. The Kernel coding style isn't actually enforced 100% though, which makes it a bit more iffy. Not all the code in the kernel actually follows the same style (IIRC, there's at least one sub-system that uses a slightly different style, I think 'net' maybe?), and so 'checkpatch' is recommended but may not be the be-all end-all in every situation.

[0] https://github.com/torvalds/linux/blob/master/scripts/checkp...

Re: Linux kernel coding style

#64

Post by kps »

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.

And it's more or less a codification of K&R style.

Re: Linux kernel coding style

#65

Post by thatswrong0 »

DSMan195276 wrote: post #60
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…

I certainly don't disagree with you on the importance of process. I was going to mention how this probably would never be an issue for the kernel.

To me, though, requiring braces would make it much easier to spot any such problem at any point in the development process (writing, debugging, reviewing, maintenance) such that the extra line per conditional would be well worth it in all cases, not to mention making edits easier.

Re: Linux kernel coding style

#66

Post by teacup50 »

jackalope wrote: post #50

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

Who cares? Get a decent editor that doesn't give a crap if there's invisible whitespace at the end of a line.

Re: Linux kernel coding style

#67

Post by uniformlyrandom »

teacup50 wrote: post #66
jackalope wrote: post #50

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

Who cares? Get a decent editor that doesn't give a crap if there's invisible whitespace at the end of a line.

or run perl -e s/(.*)\s+$/$1/g

Re: Linux kernel coding style

#68

Post by edran »

teacup50 wrote: post #66
jackalope wrote: post #50

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

Who cares? Get a decent editor that doesn't give a crap if there's invisible whitespace at the end of a line.

As the top commenter said, the problems do not end with choosing a good editor and fixing its display methodology. Git and many other VCSs create noisy diffs whenever space is added and forgotten, which ultimately complicates the life of developers that want to review changes. Even if your editor were able to make display diffs in a clean way, you would still have a dirty history when for instance using less/more or other tools (not to mention the merging issues problem).

Re: Linux kernel coding style

#69

Post by pshc »

teacup50 wrote: post #66
jackalope wrote: post #50

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

Who cares? Get a decent editor that doesn't give a crap if there's invisible whitespace at the end of a line.

Right, but that's only half of the robustness principle.

Re: Linux kernel coding style

#70

Post by userbinator »

notacoward wrote: post #47
cesarb wrote: post #38

Earlier quoted context omitted.

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…

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.

The parent provided a very good example: a structure takes up a lot more space than a single int/pointer type, and passing them by value is usually an unnecessary copy.

and need to be changed if the API ever changes.

If the API changes then changing the declarations is likely to be trivial in comparison to the other changes that would need to be made to all the code using it.

Exposing too much reduces modularity and future flexibility.

...and exposing too little reduces understanding of the details, which I think is far more important especially for a kernel.

Post reply on HN