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

191–200 of 302 posts

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

#191

Post by dragonwriter »

nurettin wrote: post #190

Often I find myself solving problems in a single performant SQL with lateral/cross joins before hitting the business logic code in order to simplify the logic part into a single loop with no conditionals/edge cases. Turns out this is not the best practice because you will have to explain all about your clever use of olap functions and lateral joins to someone less knowledgeable who has to append to your code.

I would argue that having developers that don't understand and won't bother to learn SQL working on application dependent on SQL-based DBs is the not-best-practice there, not proper and efficient use of SQL by developers who do know what they are doing.

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

#192

Post by aero142 »

ant6n wrote: post #178
colanderman wrote: post #163

Earlier quoted context omitted.

Taste is malleable and relative. One can even entertain different notions of taste. I personally have at least two – "understandable" and "performant" – and they aren't always (but sometimes are) exclusive of each other. I suspect Linus's "taste", given Linux's problem domain, tuned to some combination of performant + testable + reviewable + portable. In the example given, Linus's rewrite meets these requirements; he…

I feel at this point, the notion of 'good taste' has become even more ill-defined, something very personal. Then the notion is not very useful as a coding guideline.

There isn't a domain where taste isn't personal. It's always a blend of art and science. Just because you can't define it exactly though, doesn't mean you can't get closer to it by working at it.

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

#193

Post by [deleted] »

colanderman wrote: post #118
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 don't think anyone's mentioned that there are two functional benefits to Linus's version: testability and performance. The author touched on testability. Dropping the "if" case eliminates one code path that may contain bugs. But also, the revised code may perform a lot better if you're searching a lot of short lists. In that case, the target item has a large, though not likely, chance of being first in the list. Th…

[deleted]

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

#194

Post by 0xdeadbeefbabe »

astrobe_ wrote: post #125
jprzybyl wrote: post #63

I'm reminded of a quote from Moore in "Thinking Forth": "A lot of conditionals arise from fuzzy thinking about the problem. In servo-control theory, a lot of people think that the algorithm for the servo ought to be different when the distance is great than when it is close. Far away, you’re in slew mode; closer to the target you’re in decelerate mode; very close you’re in hunt mode. You have to test how far you are…

Be it kernel programming or Forth, the cultural shock can hit hard. Most programming languages try their best to make things easier than easy, in order to maximize programmers' productivity. The focus on this parameter alone over-promotes the "worse is better" or "good enough" mindset. That doesn't fare well with kernel programming. It's even worse with Forth. As soon as your "word" (function in Forth lingo) has to d…

Forth was practical when it was invented though.

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

#195

Post by RandomOpinion »

rukuu001 wrote: post #57
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…

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.

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

#196

Post by Roboprog »

RandomOpinion wrote: post #149
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…

Bog-standard, humdrum enterprise programming != kernel programming When every branch removed on a mainline path in the kernel saves years of compute time globally and every byte removed in the kernel saves terabytes of memory globally, being clever is absolutely the right thing to do. Removing that one branch takes away an expensive pipeline stall[0]. The version akkartik has above adds a extra branch (and expensive…

Pretty much nailed it in the first line :-)

I prefer the shorter version for being shorter, and for generalizing the update point at the end (and giving it a name), which stresses that there will be an update (delete).

Alas, most of my coworkers would prefer the "explicit" version with all of the extra lines.

Aside: I sure miss identifiers with underscores in them, rather than MashedTogetherEnterpriseSelfCrockumentingMego :-(

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

#198

Post by jordigh »

arghbleargh wrote: post #183
jordigh wrote: post #171

The example there about edges on an array is something I've had to directly deal with myself when I implemented a multidimensional image-processing function for GNU Octave. The problem is to find connected components in a binary image, where voxels are either 0 or 1. You want to find all the islands of ones, and you want to be flexible if diagonals count as being connected or not. The problem, of course, is that alon…

Isn't it simple enough to make three bounds checks to essentially do the same thing you did with the zero padding? You can even make it a function is_in_bounds(x, y, z)

It's n-dimensional, not 3-dimensional.

Also, it's really slow and wasteful to be doing bounds-checking for each voxel of an image that is almost completely not a boundary, whereas you can't avoid checking if each voxel is lit. :-)

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

#199

Post by rocqua »

dwc wrote: post #182
k__ wrote: post #141

Earlier quoted context omitted.

I thought the same. On the other hand it took me a bit of time to figure out what's going on. But I'm not C dev, so that could be the issue here.

Serious question: after figuring it out, did you have a somewhat better grasp of linked list mechanics than before?

I had a better grasp of how to work with them (am not who you replied too).

I never had to build my own linked list though. I never took those basic courses.

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

#200

Post by Roboprog »

rukuu001 wrote: post #57
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…

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.

Not sayin' you're wrong, but...

I'm going to go sit in the corner and weep, now.

Post reply on HN