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

21–30 of 102 posts

Re: Linux kernel coding style

#22

Post by oneeyedpigeon »

Dewie wrote: post #14
raverbashing wrote: post #8

I like it I really prefer using tabs. Having it displayed as 8 spaces in other languages is not as good as in C And they get it right about typedefs in C

Right, having tabs seems better since I can configure my editor to display tabs as 4 spaces, while whoever else can have tabs be displayed as 8 spaces. Having spaces instead, and having to make your tabs output spaces, and perhaps also backspace deleting four spaces (a "tab") in certain contexts, seems pretty complex in comparison.

Agreed, although this doesn't sit well with me when combined with the reasons for the recommendation - i.e. 8 is just better, line length should be 80, nesting should be limited to 3. If someone can set their indent level to something other than 8, won't they be more likely to violate other rules? I say this having just realised I have my tab set to 4 spaces ...

Re: Linux kernel coding style

#23

Post by andmarios »

snlacks wrote: post #6
kagia wrote: post #5

I doubt everyone agrees to that coding style, I certainly don't. However when submitting code to a project I'd still stick to the prescribed coding style, because I believe consistency in any code base can be just as important as any other measure of readability.

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.

Re: Linux kernel coding style

#24

Post by dezgeg »

Dewie wrote: post #14
raverbashing wrote: post #8

I like it I really prefer using tabs. Having it displayed as 8 spaces in other languages is not as good as in C And they get it right about typedefs in C

Right, having tabs seems better since I can configure my editor to display tabs as 4 spaces, while whoever else can have tabs be displayed as 8 spaces. Having spaces instead, and having to make your tabs output spaces, and perhaps also backspace deleting four spaces (a "tab") in certain contexts, seems pretty complex in comparison.

In theory, it sounds like a nice idea that by having tabs, you could choose your own preferred indent width of something different than 8 columns. But in practice, this will cause problems, such as code written by you going over the maximum line length when viewed by people with 8 column tabs.

Re: Linux kernel coding style

#25

Post by notacoward »

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 types that are the same width and signedness; why compound that stupidity? Both humans and static analyzers could tell the difference if you used typedefs, and avoid quite a few bugs as a result. Being able to change one type easily might also make some future maintainer's life much better. There's practically no downside except for having to look up the type in some situations (to see what printf format specifier to use), but that's a trivial problem compared to those that can result from not using a typedef.

Don't want to use typedefs? I think that's a missed opportunity, but OK. Don't use them. OTOH, anyone who tries to pretend that the bad outweighs the good, or discourage others from using them, is an ass. Such advice for the kernel is even hypocritical, when that code uses size_t and off_t and many others quite liberally.

Re: Linux kernel coding style

#26

Post by jmnicolas »

oneeyedpigeon wrote: post #21
davidw wrote: post #18

I'm a fan of the Tcl/Apache/BSD style. Indeed, Tcl has nice C code: https://github.com/tcltk/tcl/blob/master/generic/tclCompile....

Nice, but they definitely overcomment IMO, e.g. https://github.com/tcltk/tcl/blob/master/generic/tclCompile....

After having maintained several projects with absolutely 0 comment apart the ones that were copy pasted from examples found on the web, I can tell you there's no such thing as "overcomment".

Re: Linux kernel coding style

#27

Post by cbd1984 »

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…

Right. Use Hungarian to encode information the type system can't represent. This is relevant even in object oriented languages, such as distinguishing between escaped and unescaped strings.

Re: Linux kernel coding style

#28

Post by Dewie »

dezgeg wrote: post #24
Dewie wrote: post #14

Earlier quoted context omitted.

Right, having tabs seems better since I can configure my editor to display tabs as 4 spaces, while whoever else can have tabs be displayed as 8 spaces. Having spaces instead, and having to make your tabs output spaces, and perhaps also backspace deleting four spaces (a "tab") in certain contexts, seems pretty complex in comparison.

In theory, it sounds like a nice idea that by having tabs, you could choose your own preferred indent width of something different than 8 columns. But in practice, this will cause problems, such as code written by you going over the maximum line length when viewed by people with 8 column tabs.

My editor is set to wrap around on long lines... but that is again of course another thing that potentially has to be tweaked. That is something that is done when writing normal text (like in this text box here on this website), and is done in word processors, so it feels pretty natural.

Though I've used that (wrapping around) mostly when writing in Haskell, for some reason. In Java and whatever lines tend to not become too long, perhaps because I tend to use four space indent...

Re: Linux kernel coding style

#29

Post by why-el »

jmnicolas wrote: post #26
oneeyedpigeon wrote: post #21

Earlier quoted context omitted.

Nice, but they definitely overcomment IMO, e.g. https://github.com/tcltk/tcl/blob/master/generic/tclCompile....

After having maintained several projects with absolutely 0 comment apart the ones that were copy pasted from examples found on the web, I can tell you there's no such thing as "overcomment".

Then I think you will enjoy this thread. :)

http://stackoverflow.com/questions/184618/what-is-the-best-c...

Re: Linux kernel coding style

#30

Post by scrollaway »

Dewie wrote: post #14
raverbashing wrote: post #8

I like it I really prefer using tabs. Having it displayed as 8 spaces in other languages is not as good as in C And they get it right about typedefs in C

Right, having tabs seems better since I can configure my editor to display tabs as 4 spaces, while whoever else can have tabs be displayed as 8 spaces. Having spaces instead, and having to make your tabs output spaces, and perhaps also backspace deleting four spaces (a "tab") in certain contexts, seems pretty complex in comparison.

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.
Post reply on HN