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

151–160 of 302 posts

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

#151

Post by __jal »

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?

But I think that's part of the argument. Reasoning about edge cases in code full of nested loops and conditionals is hard. Eliminating branches and opportunities to hide fencepost errors (for instance) goes some way towards reducing cognitive noise so you can focus on the meat.

Of course that's not the full argument. And I'll throw in one more: it isn't anywhere near the top of the list in terms of importance, but aesthetically pleasing, elegant code has a certain amount of value, if only to other programmers. (Naturally, it has to be correct, too.)

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

#153

Post by facundo_olano »

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.

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

#154

Post by YCode »

Noseshine wrote: post #95
deanCommie wrote: post #87

I don't know how to reconcile Linus's track record is of indisputable brilliance and success (I use Linux and Git on a daily basis and am eternally grateful for both), with the fact that I would absolutely DESPISE working with a peer with the kinds of attitudes and opinions on coding that Linus has. I think the problem I have is that a lot of people use Linus's examples and stories as justification for their own subo…

You make claim after claim, and I think they do need substantiating evidence. After all, I find it highly unlikely that if he were even 10% as bad as you make it sound he would be the head of one of the most successful projects - especially since everybody working with him does so voluntarily. There would have been breaks long ago. The fact that the Linux kernel held together under the original author loudly speaks a…

Some food for thought: http://www.computerworld.com/article/3004387/it-management/h...

"I’m not a nice person, and I don’t care about you. I care about the technology and the kernel — that’s what’s important to me."

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

#155

Post by ant6n »

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…

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

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

#156

Post by deong »

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.

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

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

#157

Post by GrumpyYoungMan »

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 abstraction that has to do the dirty work. Because that abstraction has to be pretty and handle generic situations, it (not always but often) can't be optimized to be more efficient in specific situations.

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

#158

Post by __jal »

flomo wrote: post #15
yitchelle wrote: post #4

Earlier quoted context omitted.

Does it come down to having a deeper understanding of what is available? In your example, I guess a new engineer may not know that Where() is available, but a seasoned engineer should know. I also think that this why the social aspect of code review is so important. It is a knowledge sharing mechanism. edit: grammar

> I guess a new engineer may not know that Where() is avaiable, but a seasoned engineer should know I'd guess the opposite. Its only in the last few years that many mainstream languages have adopted this sort of functional syntax. The new engineer probably learned it right away from the docs, while the seasoned guy churns out smelly-old for loops without a second thought. GP makes a great point about different loop l…

> I'd guess the opposite.

Might depend on how trendy the new feature is. Because I still see newish Java programmers who apparently don't know that java.date.util exists, and who also don't know that rolling your own date math is only done by date manipulation library authors and connoisseurs of slow moving train wrecks.

A second, related but harder to pin down, issue exists here. I see relatively inexperienced developers who, for instance, get a little confidence with Javascript chaining and callbacks, and work themselves into corners where a given filter method (like the 'Where()' example) doesn't quite do what they need, and suddenly they have no idea what to do. So they hack in something awful in the middle, forget that it is a weird homegrown something instead of a library function, and see profoundly strange problems later.

Both of those are things programmers grow out of, hopefully. But they seem to be instances of having APIs with large surface areas causing what amounts to research failures.

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

#159

Post by majewsky »

Noseshine wrote: post #95
deanCommie wrote: post #87

I don't know how to reconcile Linus's track record is of indisputable brilliance and success (I use Linux and Git on a daily basis and am eternally grateful for both), with the fact that I would absolutely DESPISE working with a peer with the kinds of attitudes and opinions on coding that Linus has. I think the problem I have is that a lot of people use Linus's examples and stories as justification for their own subo…

You make claim after claim, and I think they do need substantiating evidence. After all, I find it highly unlikely that if he were even 10% as bad as you make it sound he would be the head of one of the most successful projects - especially since everybody working with him does so voluntarily. There would have been breaks long ago. The fact that the Linux kernel held together under the original author loudly speaks a…

I won't argue with your main point, but a fair share of kernel devs are probably not working there voluntarily, since they write kernel code for their employer.

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

#160

Post by RandomOpinion »

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.

Are you seriously arguing that Linus would think cleanly performant code is not in good taste? You're welcome to ask him that directly and see what he says.

EDIT: Okay, I'm being excessively snarky there; my apologies.

I will say instead that is that "good taste" depends on the context. What's "good taste" for kernel development isn't necessarily the same as "good taste" for enterprise development or the same as "good taste" for app development.

Post reply on HN