Live data from Hacker News

Applying the Linus Torvalds “Good Taste” Coding Requirement

medium.com

91–100 of 302 posts

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

#91

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.

This is a great point but I'm trying not to think disparagingly about the skill level future maintainers, too: deadlines and distraction are a powerful negative equalizer.

The next person to touch that code could be you, in two years after you've mostly moved on to another project / major upgrade and are back in a hurry to make a “quick” change, investigate a security report, deal with a scaling issue, etc

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

#92

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.

I agree with the condition about "If you're at BigCo". It really depends on who's going to read/edit the code, how often, and how many times it's going to be executed.

For a line of code that's going to be executed on a global scale billions of times every second, and only changed (very rarely) by extremely good developers, then I'd happily trade a bit of clarity for a bit more performance.

But if it were an oft-edited method in an in-house application that's going to be supported by junior devs? I would prefer clarity.

As always, there are no universal rules, only tradeoffs.

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

#93
post #88

Earlier quoted context omitted.

I can't see why the code from akkartik would segfault when entry is NULL? What am I missing?

If entry and head are null, segfault on line 4. If entry is null and head is valid segfault on line 10. --edit-- As pointed out by my esteemed colleagues below, I didn't read the loop conditional properly. Only the first fault applies

> If entry is null and head is valid segfault on line 10.

To get to line 10, we need prev->next == entry. Since we are talking about the case where entry == NULL, that requires prev->next == NULL

The for loop condition is prev->next, which will fail if prev->next == NULL, hence line 10 would never be reached in that case.

The difficulty of analysing all of this shows why mutable structures and variables make code hard to follow - perhaps the real good taste solution is to use something like finger trees instead of linked lists, together with a language which eliminates null.

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

#94
post #88

Earlier quoted context omitted.

I can't see why the code from akkartik would segfault when entry is NULL? What am I missing?

If entry and head are null, segfault on line 4. If entry is null and head is valid segfault on line 10. --edit-- As pointed out by my esteemed colleagues below, I didn't read the loop conditional properly. Only the first fault applies

How can you reach line 10 when entry is NULL?

(prev->next==entry) can only be true at the end of the list, but the for-condition already checks that.

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

#95

I don't know how to reconcile Linus's track record is of indisputable brilliance and success (I use Linux and Git on a daily basis and am eternally grateful for both), with the fact that I would absolutely DESPISE working with a peer with the kinds of attitudes and opinions on coding that Linus has. I think the problem I have is that a lot of people use Linus's examples and stories as justification for their own subo…

You make claim after claim, and I think they do need substantiating evidence. After all, I find it highly unlikely that if he were even 10% as bad as you make it sound he would be the head of one of the most successful projects - especially since everybody working with him does so voluntarily. There would have been breaks long ago. The fact that the Linux kernel held together under the original author loudly speaks against assumptions of "bad interpersonal skills" on the side of Linus.

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

#96

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…

Taste is dependent on the audience. An audience of kernel maintainers would probably share Linus' taste here, while an audience of enterprise developers would find the original code more palatable.

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

#97

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…

I think the specific example can create a distraction because of the use of indirection, but that there is a more general point to discuss: at what point is a chunk of code "too clever?"

One argument is that code should be written so that junior or average (or even below average) developers can be put to work on it. Another view is that part of a junior developer's learning experience ought to include not shielding him from alleged complexity or "clever" constructs, because sometimes they really are better or even unavoidable.

Cleverness for its own sake is one thing to avoid, but I think that's almost too subjective a standard to use.

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

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

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.

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

#100
post #58

I don't know why I'm even replying, this will get so much hate here, oh well... 1. Just because things aren't done "the way you would do them" doesn't mean they're "bad" or "wrong". 2. If you're not on a solo project, I've found writing correct but less "clever" code to help shorten ramp-up time for new devs and be more beneficial to future maintainability of the code-base and system. TL;DR; Swapping values by XOR'in…

Re: #2 - in Linux case, double-pointer list removal succinctly illustrates the minimum C proficiency needed for tinkering with kernel code. That is, not every project has "shortening ramp-up time" as a priority. In quite a few cases non-trivial code doubles as filter for less skilled devs.

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

Post reply on HN