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

71–80 of 102 posts

Re: Linux kernel coding style

#71

Post by robin_reala »

cesarb wrote: post #53
robin_reala wrote: post #43

Earlier quoted context omitted.

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

Interesting, thanks for the link.

Re: Linux kernel coding style

#72

Post by BugsBunnySan »

It's a very nice coding style. It keeps the code in pieces that are easy to grasp as units, it doesn't waste space and doesn't clutter the code at the same time.

Just take any random function from the kernel sources and ask yourself, what does it do. I think in most cases you'll find it's really obvious...

For me I find the kernel sources one of the most readable and understandable sources I've seen. The structure of them is just so clearly visible from the sources. I think a lot of that has to do with the coding style.

Re: Linux kernel coding style

#73

Post by andreasvc »

edent wrote: post #44
coldpie wrote: post #40

Earlier quoted context omitted.

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

This ruins the readability and usability of your diffs. Say you need to quickly track down a major bug due to a change in a single constant. With horizontal alignment, the diff might contain any number of changed lines, obscuring the crucial change. There are workarounds that ignore whitespace and word-based diffs, but it's just not worth the trouble IMHO.

Re: Linux kernel coding style

#74

Post by bryal »

eyko wrote: post #41
bryal wrote: post #10

Earlier quoted context omitted.

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

I've always thought of the GNU coding standards as an, IMO, ugly and hardly readable way of formatting C code. I didn't realize there was this much to it.

Thanks for enlightening me.

Re: Linux kernel coding style

#75

Post by Sir_Cmpwn »

andreasvc wrote: post #73
edent wrote: post #44

Earlier quoted context omitted.

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

This ruins the readability and usability of your diffs. Say you need to quickly track down a major bug due to a change in a single constant. With horizontal alignment, the diff might contain any number of changed lines, obscuring the crucial change. There are workarounds that ignore whitespace and word-based diffs, but it's just not worth the trouble IMHO.

Is this really so bad?

https://gist.github.com/SirCmpwn/540c5fc115e9f65bfa3b

Re: Linux kernel coding style

#76

Post by coldpie »

edent wrote: post #44
coldpie wrote: post #40

Earlier quoted context omitted.

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

This is true if you never change your code. But as soon as I have to add

  int rumpelstiltskin_age = 202;
to your code, I already want to throw you out the window for the work I have to do and the diff I have to ruin to keep your "pretty" formatting. Just don't bother.

Re: Linux kernel coding style

#77

Post by DSMan195276 »

thatswrong0 wrote: post #65
DSMan195276 wrote: post #60

Earlier quoted context omitted.

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…

I think it's worth noting that a pretty big percentage of the if's in the kernel are one line. I'm not particularly tied to one opinion or the other, I'll do whatever fits with the project (Though I do tend to use the one line if syntax for personal projects). But, I personally like them in the kernel's source simply because one line if's are so common and mostly encouraged. IMO, a better solution is to use a context-aware patch system, rather then line-based patches. That brings it's own set of problems though unfortunately.

That said, I think the argument does apply in that some pieces of the kernel don't strictly follow the kernel style, and the fact that braces aren't enforced leads to some uglier pieces of code [0] being allowed despite not strictly adhering to the style.

[0] https://github.com/torvalds/linux/blob/master/kernel/groups....

Re: Linux kernel coding style

#80

Post by notacoward »

userbinator wrote: post #70
notacoward wrote: post #47

Earlier quoted context omitted.

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

> a structure takes up a lot more space than a single int/pointer type

Not necessarily. Many structures, especially those used to make up for the lack of tuples/lists in C, are very small. The real difference is between large and small objects. Knowing which is which is part of the essential discipline of being a kernel (or embedded) programmer, and is hardly affected by whether or not typedefs are used.

> changing the declarations is likely to be trivial in comparison

That's generally true of pointer typedefs, which is why I don't particularly care for them and said so in another sub-thread. I think it's much less likely to be true for integer/enum or struct/union typedefs. For example, in the integer/enum case, the most common scenario is a change to a parameter's real type without changing its width or sign. The compiler won't flag that, even though it can cause real problems. Giving the compiler more information should be encouraged, not discouraged, even if there are exceptions either way.

> more important especially for a kernel.

Why do people persist in this belief that a kernel is some mystical realm where software-engineering principles don't apply? Being able to know is not the same as being forced to know. Kernel programmers are already more burdened than others with concerns that they need to think about for every line. Forcing more at them when it's not necessary doesn't help anyone. If you need to know whether something's a pointer to a struct or an array of something even though you never dereference into either (maybe you just pass it back or onward to another function), then somebody's wasting your precious time. Believe me, I know all about the tighter resource constraints for kernel code. OTOH, the people who worked on the AIX and Solaris kernels still knew and applied this stuff. They didn't have the anti-CS attitude that seems rampant among Linux kernel devs, and IMO they were better for that. If an RTOS for tiny devices can have decent modularity - and I've seen some that do - then why can't a full-blown kernel?

Post reply on HN