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

81–90 of 102 posts

Re: Linux kernel coding style

#81

Post by Perseids »

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.

I understand that it would be bad to introduce whitespace-only changes, but why would whitespace at the end of the line that doesn't break the 80 character limit be a problem otherwise? Sure, git colors them red in its diffs, but that is kind of a circular reasoning.

E.g. in this diff

  0a1
  > k=2 
  2c3,4
       k*=k 
  >     print(k)
you don't even see the spaces after "k=2" and "k*=k".

Re: Linux kernel coding style

#82

Post by dllthomas »

geekam wrote: post #78

>> Do not unnecessarily use braces where a single statement will do. Shouldn't this be changed to always use braces? Given the Apple bug?

The "Apple bug" - I assume you mean the duplicated "goto fail" - isn't really a common kind of error. That said, there are others that "braces everywhere" does protect from somewhat. The question is whether the clutter trades off too much in readability. Linus apparently thinks it does.

Re: Linux kernel coding style

#83

Post by dllthomas »

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've had luck using single-element structs to distinguish between types of data when I'm throwing a lot of primitive types around. In my test with gcc, the generated code was identical to using the primitives directly, although the standard doesn't actually guarantee that and it's historically not been the case in some particular compilers (not sure which).

Re: Linux kernel coding style

#84

Post by dllthomas »

notacoward wrote: post #80
userbinator wrote: post #70

Earlier quoted context omitted.

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

"Why do people persist in this belief that a kernel is some mystical realm where software-engineering principles don't apply?"

It's not that it's a "mystical realm where software-engineering principles don't apply", it's that - like embedded - it's a domain where you often face tighter resource constraints. Applying the same engineering principles with different constraints can lead to different trade-offs, and ultimately different best practices.

Re: Linux kernel coding style

#85

Post by dllthomas »

repsilat wrote: post #20
kijin wrote: post #13

> spaces are never used for indentation If indentation should always use tabs (0x09) and never spaces (0x20), then the whole rant about indentation width is pointless. Any modern editor will allow you to adjust the displayed width of a tab. It's only when you use spaces for indentation that the width becomes a concern.

There are two counterarguments to this: - Line length. Some people say lines should be no longer than 78-80 characters, and you can't reasonably enforce a rule like this without answering how "wide" a tab is. - Alignment. The "right thing to do" is to indent with tabs and align with spaces, but this is difficult for some people, against the religion of others (mixing tabs and spaces!) and insufficient if you want to…

I almost want a language that demands a visible character where indentation ends and alignment begins...

Re: Linux kernel coding style

#86

Post by andreasvc »

Sir_Cmpwn wrote: post #75
andreasvc wrote: post #73

Earlier quoted context omitted.

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

The problem I was alluding to occurs when a change causes the amount of alignment spaces to change, which then affects all the lines that have been aligned. Without alignment, the diff would be limited to just the code that was changed.

Re: Linux kernel coding style

#87

Post by jblow »

notacoward wrote: post #80
userbinator wrote: post #70

Earlier quoted context omitted.

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

Usually when people say stuff like this, they haven't programmed anything as complex and performant as the thing they are criticizing, so the comments can and should be disregarded as noise.

Re: Linux kernel coding style

#88

Post by mbell »

dllthomas wrote: post #85
repsilat wrote: post #20

Earlier quoted context omitted.

There are two counterarguments to this: - Line length. Some people say lines should be no longer than 78-80 characters, and you can't reasonably enforce a rule like this without answering how "wide" a tab is. - Alignment. The "right thing to do" is to indent with tabs and align with spaces, but this is difficult for some people, against the religion of others (mixing tabs and spaces!) and insufficient if you want to…

I almost want a language that demands a visible character where indentation ends and alignment begins...

It's far easier to simply ban the tab character. All indentation problems magically go away.

Re: Linux kernel coding style

#89

Post by LnxPrgr3 »

repsilat wrote: post #20
kijin wrote: post #13

> spaces are never used for indentation If indentation should always use tabs (0x09) and never spaces (0x20), then the whole rant about indentation width is pointless. Any modern editor will allow you to adjust the displayed width of a tab. It's only when you use spaces for indentation that the width becomes a concern.

There are two counterarguments to this: - Line length. Some people say lines should be no longer than 78-80 characters, and you can't reasonably enforce a rule like this without answering how "wide" a tab is. - Alignment. The "right thing to do" is to indent with tabs and align with spaces, but this is difficult for some people, against the religion of others (mixing tabs and spaces!) and insufficient if you want to…

I've been playing with clang-format for my own projects (installed via homebrew, since Apple doesn't ship it with Xcode). I tell it to enforce limits assuming ts=8 and use tabs for indentation. My editor is configured for ts=4.

Doing that seems to actually mostly work! It's made some weird (and in one case obviously broken) formatting decisions, but otherwise I'm pleased with it.

Re: Linux kernel coding style

#90

Post by Dewie »

andreasvc wrote: post #86
Sir_Cmpwn wrote: post #75

Earlier quoted context omitted.

Is this really so bad? https://gist.github.com/SirCmpwn/540c5fc115e9f65bfa3b

The problem I was alluding to occurs when a change causes the amount of alignment spaces to change, which then affects all the lines that have been aligned. Without alignment, the diff would be limited to just the code that was changed.

We should adjust our code and text to `diff`, rather than adjusting our tools to our code and text?
Post reply on HN