Live data from Hacker News

Applying the Linus Torvalds “Good Taste” Coding Requirement

medium.com

71–80 of 302 posts

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

#71

> it only performed 256 loop iterations, one for each point along the edge alarm bells There are only 252 points along the edge. This code will act on each corner twice. If you were performing an operation like `+= 1` on each edge element, this code would be wrong. When you copy and paste it later and change all the `= 0` to something else, you might end up with an unfortunate surprise. Once I saw this mistake in the…

Noticed the same thing, but only in the third, cleanest version. No better way to illustrate its merits relative to the initial two versions.

Spoiler alert: flipping that single bit from i=0 to i=1 might deserve a little comment of the "why" category.

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

#72
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.

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

#73

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…

The "bad taste" program of Linus performs two comparisons if it want to remove the first entry of the list. The "good taste" program of Linus, like your program perform only the needed number of comparisons.

For me, your program is similar to the one of Linus where you have unrolled the first iteration of the loop in order to avoid pointer syntax difficulties. Your program makes it also trivial to fix what you called the elephant. I think Linus has omit it for simplicity of example.

I like your program slightly better than the one of Linus because the syntax is less tricky, but I think the point of Linus was only the superfluous comparison in the "bad" one.

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

#74

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…

While I agree, I also think that it depends on your background. I guess pointer arithmetic should be second nature for a kernel developer? So there might not be much clarity cost then.

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

#75

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…

Screw 'taste', go for obvious . If you're at BigCo and your codes going to be maintained by disinterested drones/ random contractors/etc, obvious code is better. And lack of checking on entry pissed me off too.

Totally agree, never play code golf with your production code. Your cleverness will bite you in the arse when you can't be promoted or allowed to move to a new project, because your code is so clever that you're the only one who can properly maintain it.

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

#76

Earlier quoted context omitted.

Screw 'taste', go for obvious . If you're at BigCo and your codes going to be maintained by disinterested drones/ random contractors/etc, obvious code is better. And lack of checking on entry pissed me off too.

Totally agree, never play code golf with your production code. Your cleverness will bite you in the arse when you can't be promoted or allowed to move to a new project, because your code is so clever that you're the only one who can properly maintain it.

[deleted]

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

#77
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 -…

I definitely agree with this, but note that the semantics in your code are different from those in Linus's example - your code filters out ALL matches.

This is actually an important point. Quite a few times I've written something that started as a list comprehension, changed it to a lambda later in the sprint and finally to a loop when the requirements became more detailed. - The real world is unfortunately full of business requirements that think that they are special flowers.

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

#78

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 didn't know that whiles were less normal than fors.

And though I don't object to for loops in this situation, I really had to puzzle yours out, because of the way your loop pointer is one behind the place of interest.

I believe you when you say it is segfault-free, but again I would have to puzzle at the code to be sure.

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

#79

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…

Like Linus example, this is just an example too and does not cover or comment on all the issues, so there are still elephants lurking in the shadows, just to name a few:

- Can entry be NULL? (segfault)

- Can head be NULL (list is empty)? (segfault)

Since the Linus example has the apparent precondition that the entry to be removed must be present in the list, there are no segfaults with proper API use. Since your code tries to eliminate that precondition, I'd argue "Remove NULL from the list" and "Remove something from an empty list" is something to expect, but you didn't account for that.

Point being: Don't be overly critical of examples; they are just examples.

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

#80

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…

Actually, I find the double pointer version easier to understand, and incidentally it is also the way always wrote this in C. And I pitied the pascal programmers who had to use the original version.

'Simplify so a fool can understand your code, and you will have fools editing it.'

Post reply on HN