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

101–110 of 302 posts

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

#101

Post by sidlls »

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

Well the second snippet hides the loop and conditional which surely are implemented in "Where". Is that a code smell by proxy?

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

#102

Post by lallysingh »

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…

Link to the book: http://thinking-forth.sourceforge.net/

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

#103

Post by vetinari »

vacri wrote: post #67
gknoy wrote: post #55

Earlier quoted context omitted.

Switch statements have fall-through behavior that you need `break` to avoid (in most languages); sometimes this is what you want, but only rarely. 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,…

Thanks to both of you for the info. I haven't played with lambdas much yet, perhaps this is the time to start :)

Lambdas in Python are somewhat limited - the syntax allows for only one expression. You can use inner (nested) functions however.

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

#104

Post by krylon »

sidlls wrote: post #101
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 -…

Well the second snippet hides the loop and conditional which surely are implemented in "Where". Is that a code smell by proxy?

In a way, yes. On the other hand, it boils down the code that some poor soul of a maintenance programmer needs to deal with to a single line which is more readable, too. Win-Win.

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

#105

Post by krylon »

PJDK wrote: post #45
prewett wrote: post #29

Earlier quoted context omitted.

In case any other seasoned C++ engineers are worried that they have missed something big in all the new C++ specs, the above code seems to be C#.

It is, sorry,I should have specified. Also I don't think many people would use a loop like that when foreach is available.

Having made my fair share (if not more) of terrible (and terribly embarrassing) errors in C using the for-loop, I love foreach and its brethren in other programming languages. I only write classical C-style for loops very, very rarely these days.

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

#106

Post by sidlls »

krylon wrote: post #104
sidlls wrote: post #101

Earlier quoted context omitted.

Well the second snippet hides the loop and conditional which surely are implemented in "Where". Is that a code smell by proxy?

In a way, yes. On the other hand, it boils down the code that some poor soul of a maintenance programmer needs to deal with to a single line which is more readable, too. Win-Win.

I don't disagree. But then again I've had peers review code similar to this and flag an issue saying it's too clever because that poor soul might not know what "where" is doing or that the use of lambdas is "too complex."

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

#107

Post by zAy0LfpBZLC8mAC »

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…

Really, if you think the good version is overly clever, you probably have a very fundamental problem with your abstract reasoning. A very human one, as history is full of people having that problem--and ultimately, the good version taking over anyway.

How about this:

    subtract(n){
        if(n==0){
           return m;
        }
        r=m;
        for(x=0;x
People for a long time had strong objections to a number "0", because it doesn't make sense to have a number for nothing! Why not just have no number at all! 0 is not a number, it's a special case! Wrapping it up in arithmetic like that is just overly clever! After all, 0 is not a number!

The whole problem with that is the preconceived and completely unjustified notion that 0 is not a number. Just accept that 0 is a number, and suddenly, things become much easier to reason about, much more elegant to work with.

Similarly, the whole problem here is that you have the preconceived and completely unjustified idea that removing the first element is a special case. You can define it to be, just as you can define 0 to be a special case. But you could just as well simply let go of that preconceived idea and accept that it's not, and suddenly all the problems that you imagine are there disappear, and you have simpler code, just as having integer types with a zero makes for simpler code.

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

#108

Post by palunon »

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.

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

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

#109

Post by [deleted] »

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…

[deleted]

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

#110

Post by makomk »

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.

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.
Post reply on HN