Live data from Hacker News

Applying the Linus Torvalds “Good Taste” Coding Requirement

medium.com

51–60 of 302 posts

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

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

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

#52

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 agree with you that moving the conditional to the beginning as an early exit keeps things simple, and while I don't see anything unusual about a 'while' loop and feel they have their place, this 'for' definitely works well.

I would make one small tweak, replacing this line

    prev->next = prev->next->next;
with

    prev->next = entry->next;
Just makes it a bit more straightforward to understand (as well as infinitesimally more efficient).

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

#53
post #3

I think "competitive" (i.e. solving algorithmic challenges for fun) coding really gives you some insight into how to write code that's short and to the point. The user with the most reputation on LeetCode, for example, consistently posts solutions that are surprisingly short, efficient, and readable. https://discuss.leetcode.com/user/stefanpochmann (some random examples) https://discuss.leetcode.com/topic/18731/7-lin…

The code might be short and to the point, but it definitely is not easy for me to understand!

The code feels like a bit like clever perl one-liners.

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

#54

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…

This version is more clear for a human, but it does contain duplicate logic.

This line:

          head = head->next;
is another form of this line:

              prev->next = prev->next->next;
Both delete by setting "->next". Code duplication is a common source of bugs, and that's the rationale behind Linus's version, which eliminates duped code.

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

#55
post #34

Speaking of coding niceties, when I started branching out from bash into a 'real' language, Python, I couldn't find a switch statement. A colleague of mine said that Python didn't have one, and that switch statements were a 'code smell'. I didn't really understand that, and asked about those times that you genuinely could use a switch statement, and the answer was "just use a long if-else function". I can't remember…

Switch statements have fall-through behavior that you need `break` to avoid (in most languages); sometimes this is what you want, but only rarely.

One trick I've seen people do in Python is to use a dict; define lambdas for each case, and then key the dict on your value that you would switch on, and invoke the lambda (or use existing functions).

    def fake_switch(self, thing):
        {
            'foo': self.do_foo,
            'bar': self.do_bar,
            'frog': self.blast_vent_core
        }[ thing ]()
I am doing a poor job of explaining _why_ one might want to do that, but one advantage is that you can verify that the right callbacks were called in tests, and also verify that each callback behaves right when invoked, since they are just references to methods or functions. I'm not sure if doing this would get marks for cleverness and testability, or would get one criticized for excessive cleverness. As the reviewer of the code when a coworker wrote it, I recall liking it, though.

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

#56

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…

An early exit is not the worst thing in the world, but an edge case is still an edge case. And if you have full "end of list" checks you make it even worse because now you're doing that in two places too. And if you do something with the entry, now that's in two places.

Sure, the case where it's the head of the list is simpler by itself. But treating it specially means more code, and more duplication, and it's not even faster.

To criticize the cleverness of Linus' code is fine. But the algorithm is the argument here, not the specific way he wrote it.

Edit: Also, I don't really buy into your argument about for loops. You trade one problem for another. Your version won't segfault (except the case where it does), but it will silently fail to remove anything.

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

#57

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.

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

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

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

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

Projects should be accessible to new developers regardless of their complexity level. Even operating systems. Otherwise they will simply stagnate and die.

Also, "less skilled devs" are just people that are still learning. We've all been there.

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

#60

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…

>What is "tasteful" about hiding the fact that one of the cases is far simpler than the other?

The fact that this is an implementation detail and not a universally true fact about the two cases?

Post reply on HN