Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Applying the Linus Torvalds “Good Taste” Coding Requirement

medium.com

Post reply on HN
Print view View original

201–210 of 302 posts

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

#201

Post by eatbitseveryday »

avip wrote: post #126
akkartik wrote: post #13

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'd add something like assert (head && entry) up there.

A NULL head is not an error (= empty list) and 'assert' would be better as a BUG_ON or panic if it is technically an error.

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

#202

Post by Roboprog »

RandomOpinion wrote: post #195
rukuu001 wrote: post #57

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.

For heaven's sake, everyone, please stop getting hung up on the fact that there's no error checking. Example code usually doesn't show error checking because it obscures the main point of the example.

Not shown: assertions :-)

(which, for kernal code, would be turned off later, anyway)

In languages other than C, with exceptions and stack traces, most precondition checks just become clutter, anyway. Although it would be nice to have "Eiffel" style pre/post-condition (invariant assertion) blocks out-of-line that can be enabled or disabled...

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

#203

Post by abecedarius »

AceJohnny2 wrote: post #8

These are great examples, and they hint to, but do not mention, the big counterpoint: development time. In his own examples, the author admitted that though the code was ugly, it worked. He then spent extra time reworking the existing code to make it, well, prettier. "If I had more time, I would have written a shorter letter." -- Voltaire The problem is that, in many (most?) professional settings, the developer is un…

While the improvement might or might not be worth the cost of figuring it out for this case in isolation, note that a more experienced programmer would write the final better version first, without even considering looping over the whole 2d array. How do you learn to do that? By revising your code!

If you never get to learn better, you're letting your management force you to retard your own development. Unless you're a temp it's probably even costing your employer more than it gains. Of course, there's a balance between learning and firefighting. Just don't put the fulcrum all the way over on the left edge.

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

#204

Post by ehsanu1 »

GrumpyYoungMan wrote: post #157
PJDK wrote: 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 -…

You don't know what that Where() costs you, though. The abstraction in your second snippet does _at least_ as much work as the code in the first snippet _and_ has an unknown level of extra overhead. Abstractions are not free. Because we can almost always afford the luxury of abstractions, some people forget that there's an engineering tradeoff there. There's always something underneath that nice, pretty-seeming abstr…

Zero-cost abstractions are a thing though. Compiler magic can even fuse together multiple calls like this on the same collection into the equivalent regular loop. So it can in fact be faster rather than slower, in the right context.

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

#205

Post by sidlls »

agentgt wrote: post #144
rukuu001 wrote: post #57

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.

I say screw 'taste' and 'obvious' and instead go for it has high coverage unit tests and lots of them . You can always go back and make it look pretty safely with good tests. I just love code snobs that think their code is so good they don't need tests.

Counterpoint: test code is also code and when unit test tyrants rule a team it can easily break down into a mess of maintenance (which suddenly more than doubles).

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

#206

Post by trop »

no_protocol wrote: post #12

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

Here is which seems to be idiomatic in digital photo processing (e.g. darktable):

  for (int r = 0; r = 1 && j
Of course, this one has a conditional, and many would frown on mucking with the loop counter outside of the for statement.

A source for this style may be dcraw, e.g. see from border_interpolate():

  for (row=0; row = border && row
The dcraw code is so tightly written that I assume Dave Coffin has good reason for this choice, but I've never tested variants for performance.

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

#207

Post by vilya »

usefulcat wrote: post #152

Is it just me or does the grid initialization example seem extremely contrived?

I thought that too. I found it hard to believe that anyone would write either of the first two versions without having thought of the 3rd - or, you know, just having 2 or 4 separate for loops. Maybe there was something about the problem's context that the author left out of the post though?

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

#208

Post by saosebastiao »

I know Sufficiently Smart Compilers are a running joke, and I know a lot of people think the idea is a bad one, but come on...this should be the job of a compiler. The first example is way more understandable. Yes, it branches, and yes it is more code and less efficient. But a compiler should be able to derive the more efficient version from the more understandable code. And it's a shame that it doesn't.

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

#209

Post by akkartik »

adrianratnapala wrote: post #78
akkartik wrote: post #13

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.

I think I'd be ok with a `while` that looked like this:

  while (prev->next) {
      if (prev->next == entry) break;
      prev = prev->next;
  }
or even this:

  while (prev && prev->next != entry)
      prev = prev->next;
Both are reasonable enough that they wouldn't trigger my (pretty laissez faire) sense of "taste". My core point: checking for the end of the list should be non-negotiable.

The `for` is just extra icing: it creates a scope for `prev`; you can tell at a glance that it's traversing a list. The update is closer to the termination check. But yes, this bit is negotiable.

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

#210

Post by akkartik »

tempestn wrote: post #52
akkartik wrote: post #13

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…

Yes, I'd be ok with a `while` that checked for the end of the list: https://news.ycombinator.com/item?id=12798192

I really try not to be a nazi about this sort of thing. Very few things matter enough to get into a HN conversation about "taste".

Post reply on HN