Live data from Hacker News

Applying the Linus Torvalds “Good Taste” Coding Requirement

medium.com

181–190 of 302 posts

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

#181

The root of the problem is that "the thing that points to an entity" is not a consistent concept in this kind list. Sometimes it's "head", sometimes it's an entity's ->next. I wonder what Linus would think of implementing the linked list with a dummy head node, having no value and pointing to the first entity. Personally, I think that would be tasteful. It allows for simple loops like the "good taste" one, but you do…

It's one more pointer that you have to resolve, everytime you do something with the list. Sounds smelly to me.

Depends on where you store it. If you're just passing around node pointers, then you could create the dummy node on the stack only when you need it and it's the same indirection cost as the "indirect" pointer. If you've got a "list" struct that you're passing around (pretty unlikely in C), you could embed the dummy node directly.

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

#182
post #141
post #128

Linus' "good" version has a McCabe cyclomatic complexity of 2, whereas the "bad" version has a value of 3. So, objectively, one could argue there is improvement there (albeit small). Validation of the "good" version will be easier (e.g. code coverage testing) with fewer paths through the code. Additionally, a lower cyclomatic complexity typically implies less stress on the developer's working memory while reading cod…

I thought the same. On the other hand it took me a bit of time to figure out what's going on. But I'm not C dev, so that could be the issue here.

Serious question: after figuring it out, did you have a somewhat better grasp of linked list mechanics than before?

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

#183

The example there about edges on an array is something I've had to directly deal with myself when I implemented a multidimensional image-processing function for GNU Octave. The problem is to find connected components in a binary image, where voxels are either 0 or 1. You want to find all the islands of ones, and you want to be flexible if diagonals count as being connected or not. The problem, of course, is that alon…

Isn't it simple enough to make three bounds checks to essentially do the same thing you did with the zero padding? You can even make it a function

    is_in_bounds(x, y, z)

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

#184
post #98

Earlier quoted context omitted.

It's not simplifying it though, it's just hiding the complexity in syntactic sugar. I prefer the first way of doing things vastly over the second. Yeah, it's more code, but it's also more or less "what is actually happening", instead of an euphemism which has to be unpacked.

> it's just hiding the complexity in syntactic sugar. And that complexity is only written once, instead of multiple times for a single project You can have as many FOR and IF branches that you want, but only if they are all bugless!

Yep. As long as the abstraction is tested and functions as advertised it can be very useful.

I'd much rather see a few lambdas in a chain of function calls than blocks of conditionals and loops. Every keyword or bit of code that has to be typed is a potential source of errors, and abstractions of this sort help minimize that.

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

#185
post #2

I was given a piece of advice very early on in my career that I've always been grateful for, which is fundamentally the same as this. IF and FOR are both code smells. One case of this is just simplifying loops with some functional goodness var listOfGoodFoos = new List (); for(var i = 0; i VS return listOfAllFoos.Where(x => x.IsGood); But perhaps a more interesting point is it can also be a a sign of DRY gone wrong -…

That is more imperative programming (your first example) vs. functional programming (your second example). The problem with functional programming is that you need to know how the functions are implemented to be able to estimate performance.

Especially for something like kernel code, which was the original example. "Obvious cost" matters at least as much as "obvious code" in that world.

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

#186

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…

Btw the second "tasty" solution in the article may not taste well to cache lines. May just be better to do three separate loops.

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

#187
post #100

Earlier quoted context omitted.

>In quite a few cases non-trivial code doubles as filter for less skilled devs Right, until the less skilled dev it's you, months later after you moved on to other stuff, and have to get back and fix some clever shit you wrote but don't understand anymore. Unless you're doing numeric or performance critical work, code should be optimized for readability and maintainability.

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.

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

#188

Earlier quoted context omitted.

>So which is objectively better probably depends on your audience. I guess when your audience is kernel developers, this isn't that much of a problem...

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

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

#189

Earlier quoted context omitted.

I completely agree (tho you're getting downvoted by others). Linus's code here is 'clever'... but not good, simple code.

It's a long time since I wrote much C but Linus' version seems like idiomatic C to me. The use of pointers in C is an ordinary thing and those who write a lot of C should be fluent in their use. It's interesting to apply the same technique to other languages. I have to use VB.net most of the time so here are implementations of the tasteless and tasteful versions in VB (untested so there might be bugs). Even in VB the…

[deleted]

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

#190
Often I find myself solving problems in a single performant SQL with lateral/cross joins before hitting the business logic code in order to simplify the logic part into a single loop with no conditionals/edge cases.

Turns out this is not the best practice because you will have to explain all about your clever use of olap functions and lateral joins to someone less knowledgeable who has to append to your code.

Post reply on HN