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

161–170 of 302 posts

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

#161

Post by agentgt »

deong wrote: post #156
agentgt wrote: post #144

Earlier quoted context omitted.

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.

> You can always go back and make it look pretty safely with good tests. Yeah, but you won't. I think that's part of the reason why people care about "taste". I want to maximize the chances that essentially the first draft is good enough to be maintained for as long as possible, because years of hard-won experience has taught us that it will.

> Yeah, but you won't. I think that's part of the reason why people care about "taste".

Ahh but you eventually will (at least in my experience). If you don't need to the code either doesn't matter (dead code) or works just fine.

I think I have looked at my own companies entire code base a couple of times. Do I see nasty crap... all the time. And I often fix it for good taste when it is really bad but I have to say the value prop isn't very good compared to adding tests or other automated validation (including automated profiling and dead code analysis).

Kernel code and in particular C are sort of special cases because they are hard to test and performance is generally a high concern. But for many other higher level languages and problem domains this is not the case.

I have been meaning to look how at how much code bases change overtime. In the case of Linux I wonder how much of the Kernel code has stayed the same (lets say over a 5 year period). Probably not a ton but I bet for other domains particularly business software the code either just dies or changes dramatically over time.

Then there are I suppose other domains where the code really can't physically change often (ie space probes and embedded devices).... for those systems I really really hope they have lots of tests.

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

#162

Post by wang_li »

danielsamuels wrote: post #119
tomerv wrote: post #90

Earlier quoted context omitted.

Here's my fix: for (i = 0; i This way, for every row/column, the loop acts on all but the last cell, which is actually the first cell of some other column/row.

I feel like for the each side you could actually handle two items per iteration, one forwards _and_ one backwards. That way your iteration count could be halved.

And what do you do with odd grid sizes?

Honestly the whole second half seemed damned weird. Give the requirement to zero the edges of a two dimensional array, it's so astonishingly obvious to just hard code the 0 and width-1/height-1 that do do anything else suggests a special effort to make a sub-optimal solution simply for arguments sake.

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

#163

Post by colanderman »

ant6n wrote: post #155
RandomOpinion wrote: post #149

Earlier quoted context omitted.

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…

But now you're making argument about performance, not "good taste". Often, performant code is not very tasty.

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; hence his assertion that it is in better taste.

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

#164

Post by smitherfield »

tempestn wrote: post #22

Not being used to C syntax, I took this as a typo at first: indirect = &(*indirect)->next; The position of the parentheses make it look like you're dereferencing only (* indirect). But on second look, you need the parens there so that it's (* indirect)->next as opposed to indirect->next. Then the & operates on the whole thing. I'd be tempted to wrap it in a second set of parens for clarity, but perhaps it's entirely…

It's quite clear to me[0]: The member access and subscript operators (. -> []) have the highest precedence, and the pointer dereference and address-of operators (* &) bind from right to left. And in any event if you left out the parentheses the compiler or IDE would likely catch your error.

[0] As someone who likes coding in C/C++ for fun but has never for my day job.

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

#165

Post by thegenius2000 »

makomk wrote: post #110
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.

If you understand C pointers, this is obvious: it keeps track of where the pointer to the current node came from, and replaces it with a pointer to the next node once it reaches the entry to be removed.

I agree, in fact taste might rightfully be defined as that which is obvious to an experienced developer in the environment. Code which simply relies on conventions and avoids complexity is often immediately elegant.

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

#166

Post by jsli »

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.

Define obvious. At least the pointer pointer version is obvious to me in this task.

Pointer pointer can't be applied everywhere. If you try to reverse a linked list in O(n) time with O(1) space using a pointer pointer, the code would be less obvious than using a prev pointer.

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

#167

Post by colanderman »

IshKebab wrote: post #120
palunon wrote: post #108

Earlier quoted context omitted.

>If you're at BigCo and your codes going to be maintained by disinterested drones/ random contractors/etc, obvious code is better. But what if you're Linus Torvalds and maintaining the Linux kernel ?

Obvious is still important. Even kernel developers make mistakes. The 'good taste' example may be more concise but how likely are you to spot bugs in it?

More likely, because there are fewer code paths to follow. Given Linus's explanation, I think that's part of the basis of his "taste", not conciseness (which in this example I suspect is a byproduct).

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

#168

Post by majewsky »

palunon wrote: post #117
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…

"If I had more time, I would have written a shorter letter." -- Voltaire You're quoting Pascal, not Voltaire ;)

"The worst thing about the internet is how quotes are always misattributed." - Albert Einstein

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

#169

Post by smitherfield »

phee wrote: post #100
eps wrote: post #58

Earlier quoted context omitted.

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.

If this example is too "clever" for someone, even sight unseen, they aren't (yet?) cut out to be a kernel hacker. I don't disagree with your general principle, but the linked example is idiomatic and understandable C for someone with a decent knowledge of the language, which is (I'd imagine/hope) the standard expected of contributors to Linux.

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

#170

Post by dpark »

facundo_olano wrote: post #153

All due respect to Linus, but the second example is much less readable. Proof of that: the code was reduced in half, but the amount of comments was doubled. I think concepts like "elegance" and "good taste" of code should exist, but they are obviously subjective. My choice of good taste always considers readability first.

I'm pretty sure that the comments are for people who Linus doesn't want contributing to the kernel. This code would likely have no comments at all if checked into the Linux kernel because it would be obvious to everyone allowed to do commits.
Post reply on HN