Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Applying the Linus Torvalds “Good Taste” Coding Requirement

medium.com

Post reply on HN
Print view View original

211–220 of 302 posts

Re: Applying the Linus Torvalds “Good Taste” Coding Requirement

#211

Post by smitherfield »

phee wrote: post #187
smitherfield wrote: post #169

Earlier quoted context omitted.

If this example is too "clever" for someone, even sight unseen, they aren't (yet?) cut out to be a kernel hacker. I don't disagree with your general principle, but the linked example is idiomatic and understandable C for someone with a decent knowledge of the language, which is (I'd imagine/hope) the standard expected of contributors to Linux.

Actually I believe this particular example is basic and pretty understandable C. I was talking about the more broad idea of knowingly writing clever code to raise the entry barrier for new devs. Or just writing clever code for whatever the reason. It's almost guaranteed to backfire, to new devs who will have to maintain it or to yourself, when you will have to read it in a less smart moment.

Entirely agreed.

Re: Applying the Linus Torvalds “Good Taste” Coding Requirement

#212

Post by akkartik »

illys wrote: post #116
akkartik wrote: post #13

I dunno, the first example seems unsatisfying. The original has that ugly condition, the "good" version seems overly clever. And for all the talk of taste and aesthetics, both versions ignore an elephant in the room: defensively dealing with `entry` being absent from the list. Not that I've never abused addresses like this. But having written this multiple times, I currently prefer something like this: remove_list_en…

Independently of style, taste, BigCo, edge cases, assumptions and other considerations, I still find a major regression in your version: Instead of one variable allocation and one test in the loop, your version has one allocation and TWO tests. Adding weight in loops has a major performance impact.

Oh, absolutely. I have a long history of preferring code to be safe rather than fast[1]. In this case, for any project I had a say in you'd have to convince me with concrete measurements that this particular loop was on the critical path, and then you'd have to write a dozen tests to convince me that it was being used right without the terminal check, and that any future users would get unambiguous errors in debug mode. And after all that, you wouldn't be allowed to claim that taking away one of the conditions is "tasteful".

I actually tend to be pretty lax about coding style, believe it or not. But dereferencing NULL is undefined behavior.

[1] My guru in this regard is DJ Bernstein: https://cr.yp.to/qmail/qmailsec-20071101.pdf

Re: Applying the Linus Torvalds “Good Taste” Coding Requirement

#213

Post by TickleSteve »

RandomOpinion wrote: post #188
TickleSteve wrote: post #146

Earlier quoted context omitted.

not true at all.... kernel developers are not mythical beasts, they're just regular low-level developers. Nothing special. I've got 20 years experience developing this kind of stuff and to me, its not as simple as it could be, therefore it could be better.

You have 20 years of experience on this kind of stuff and don't recognize the textbook example code for handling the head pointer case of a linked list? Well, okay... (It's at least 23 years old because I learned from textbooks that have this example code way back then. It probably dates all the way back to K&R.)

What textbook would that be exactly?? (not that it matters)

The point isn't "can I understand it"...

the point is "Would someone who hadn't seen it before have to do another mental operation to understand it?"

...and yes... dereferencing is another operation you have to do in your head to understand it.

Re: Applying the Linus Torvalds “Good Taste” Coding Requirement

#214

Post by leothekim »

This article made me think of this Gordon Bell quote:

"The cheapest, fastest, and most reliable components are those that aren’t there."[1]

That quote is a reminder to me that there is a certain artistry behind engineering anything.

[1] http://quotes.cat-v.org/programming/

Re: Applying the Linus Torvalds “Good Taste” Coding Requirement

#215

Post by akkartik »

RandomOpinion wrote: post #149
akkartik wrote: post #13

I dunno, the first example seems unsatisfying. The original has that ugly condition, the "good" version seems overly clever. And for all the talk of taste and aesthetics, both versions ignore an elephant in the room: defensively dealing with `entry` being absent from the list. Not that I've never abused addresses like this. But having written this multiple times, I currently prefer something like this: remove_list_en…

Bog-standard, humdrum enterprise programming != kernel programming When every branch removed on a mainline path in the kernel saves years of compute time globally and every byte removed in the kernel saves terabytes of memory globally, being clever is absolutely the right thing to do. Removing that one branch takes away an expensive pipeline stall[0]. The version akkartik has above adds a extra branch (and expensive…

Yes, of course, I'm certainly not cut out to be a kernel programmer. Were the audience in that TED chat kernel programmers? I thought we were discussing "taste", not what it takes to get a patch into the kernel. Linus does work on other projects, you know.

Re: Applying the Linus Torvalds “Good Taste” Coding Requirement

#216

Post by hairy_man674 »

johan_larson wrote: post #23

For my money, Linus's example of "good taste" gives up rather a lot of clarity to achieve succinctness. The original is simple and clear. His preferred version is shorter, but also harder to understand because of its use of a complicated indirection. And that's not good taste. It's just showing off. “Programs must be written for people to read, and only incidentally for machines to execute.” ― Harold Abelson, Structu…

In userspace this is generally true, and it sucks because "good taste" should really be an engineering determination not compromise to human laziness and mediocre slackers.

Re: Applying the Linus Torvalds “Good Taste” Coding Requirement

#217

Post by nickpsecurity »

Roboprog wrote: post #202
RandomOpinion wrote: post #195

Earlier quoted context omitted.

For heaven's sake, everyone, please stop getting hung up on the fact that there's no error checking. Example code usually doesn't show error checking because it obscures the main point of the example.

Not shown: assertions :-) (which, for kernal code, would be turned off later, anyway) In languages other than C, with exceptions and stack traces, most precondition checks just become clutter, anyway. Although it would be nice to have "Eiffel" style pre/post-condition (invariant assertion) blocks out-of-line that can be enabled or disabled...

SPARK does that with efficient, system code. Then proves the code free of common errors in C. Then other tools can generate unit tests from the specs just in case. Frama-C does something similar for C. I'm not sure what the usability or thoroughness is like vs SPARK, though.

http://www.spark-2014.org/about

Re: Applying the Linus Torvalds “Good Taste” Coding Requirement

#218

Post by zodiac »

saosebastiao wrote: post #208

I know Sufficiently Smart Compilers are a running joke, and I know a lot of people think the idea is a bad one, but come on...this should be the job of a compiler. The first example is way more understandable. Yes, it branches, and yes it is more code and less efficient. But a compiler should be able to derive the more efficient version from the more understandable code. And it's a shame that it doesn't.

I think Linus argued that the second version is more understandable.

In fact if you read the article there's no claim being made that the second version is more efficient, and I don't think it is

Re: Applying the Linus Torvalds “Good Taste” Coding Requirement

#219

Post by kilburn »

colanderman wrote: post #118
akkartik wrote: post #13

I dunno, the first example seems unsatisfying. The original has that ugly condition, the "good" version seems overly clever. And for all the talk of taste and aesthetics, both versions ignore an elephant in the room: defensively dealing with `entry` being absent from the list. Not that I've never abused addresses like this. But having written this multiple times, I currently prefer something like this: remove_list_en…

I don't think anyone's mentioned that there are two functional benefits to Linus's version: testability and performance. The author touched on testability. Dropping the "if" case eliminates one code path that may contain bugs. But also, the revised code may perform a lot better if you're searching a lot of short lists. In that case, the target item has a large, though not likely, chance of being first in the list. Th…

I'm not a low level programmer, so this is a honest question.

In the better version, why doesn't the while condition (that must be tested at least once) present predictability problems whereas the if check in parent does?

Re: Applying the Linus Torvalds “Good Taste” Coding Requirement

#220

Post by clarry »

Animats wrote: post #38

Both versions suck. If "entry" is not found in the list, the code will run off the end of the list, either de-referencing zero and faulting or going off into junk, depending on how the list ends. Writing low-level list manipulation more than once sucks. It leads to bugs. Such manipulation should be encapsulated. That's why we have containers in modern languages. The Linux kernel is still C, not C++, which leads to to…

I think practicing C programmers are using the list implementations that were given to us two decades ago. Or any of the newer alternatives. And if they aren't, it's not because of the language.
Post reply on HN