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 -…
Applying the Linus Torvalds “Good Taste” Coding Requirement
51–60 of 302 posts
Re: Applying the Linus Torvalds “Good Taste” Coding Requirement
#52I 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 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
#53I 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 feels like a bit like clever perl one-liners.
Re: Applying the Linus Torvalds “Good Taste” Coding Requirement
#54I 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 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
#55Speaking 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…
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
#56I 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…
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
#57I 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…
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
#58I 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…
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
#59I 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.
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
#60I 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 fact that this is an implementation detail and not a universally true fact about the two cases?