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

Clear is better than clever [pdf]

dave.cheney.net

Post reply on HN
Print view View original

101–110 of 335 posts

Re: Clear is better than clever [pdf]

#101

Post by coldtea »

jodrellblank wrote: post #87
Random_Person wrote: post #70

Earlier quoted context omitted.

I couldn't disagree more. Nested ternarys are NEVER okay. They are confusing and misleading to anyone new to your code base.

They are confusing and misleading to anyone new to your code base. But why should that be the main thing to be concerned about and prioritise? In what way are they "misleading"? Is it really the state of the industry where a new person cannot learn a codebase, has no time or effort, and cannot read a single line of the language they were hired to work on, and that's the person we should build everything for? Does it…

>Is it really the state of the industry where a new person cannot learn a codebase, has no time or effort, and cannot read a single line of the language they were hired to work on, and that's the person we should build everything for?

Seasoned 10x developers, titans of the industry, and all agree on simplicity and even they frequently make mistakes on easily confusable constructs such as nested ternaries (or even BS like forgetting a break in a switch etc).

It's not some bad "state of the industry" that calls for no such constructs.

If anything, it's amateurs and newbs, more self-confident than they should be (and less humble) that call for using any old crap in a language, and think that such constructs are only problematic if developers are "not paying attention" or are "ignorant".

Re: Clear is better than clever [pdf]

#102

Post by maxxxxx »

brmgb wrote: post #72
userbinator wrote: post #21

It's interesting that the comparator function is one of the examples, because that's something which shows how people often confuse verbose with clear ; I think it's best written in a single line: return a b ? 1 : 0; That's one line, compared with the 10(!) of his proposed method using a switch statement. Having worked with some "modern" codebases, I think verbosity is a bigger problem that's become especially preval…

I tend to avoid the ternary operator because in my experience even people who think they know how it works are often unaware of its edge cases when it comes to silent numeric type conversion (looking at you Java). If you don't put the same type on each return sides of your ternary, you might be in for a nasty surprise.

“If you don't put the same type on each return sides of your ternary, you might be in for a nasty surprise.”

Definitely true for JavaScript and PHP. I am always surprised what expressions can evaluate to true or false.

Re: Clear is better than clever [pdf]

#103

Post by jlokier »

deng wrote: post #61
illys wrote: post #39

Earlier quoted context omitted.

Fully agree! Combinations of if/else can seriously damage readability and maintainability. I (all the time) face verbose code that pretend to be readable and that requires lots of attention just to find out you are setting a single variable across 10-20 lines. Example: if (cond1) { myVar = 1; } else if (cond2) { if (cond3) { myVar = 10; } else { myVar = 100; } ... } else { myVar = defaultValue; } * huge number of lin…

> Combinations of if/else can seriously damage readability and maintainability. Yes, that's why for selections we usually use switch/case. But of course every programmer worth his money just knows that ?: is right associative and that '&&' is on precedence level 11 while '?:' is on 13. If that's not "clever code", I don't know what is...

> every programmer worth his money just knows that ?: is right associative

I would hope every programmer worth their money are very comfortable with it, because chaining like this is a very common syntactic pattern in other people's code:

  cond1 ? val1 : cond2 ? val2 : cond3 ? val3 : other
It is made less readable if you turn it into a right-nested mess of parentheses, so that is rarely seen.

Just as nobody thinks of 'if..else' as right associative, but it actually is, and everyone uses that fact without thinking about it.

Same for '?:'. The associativity is just a formality that nobody thinks about.

> '&&' is on precedence level 11 while '?:' is on 13

On this I agree. I routinely put parentheses around complex conditions on the left side of ternaries for this reason.

I do remember the precedence, but I think leaving the parentheses out can raise a little doubt in the reader's mind, because it is common to use logical operators for control flow in languages like JavaScript, and control flow is at the same conceptual level as '?:'.

Re: Clear is better than clever [pdf]

#104

Post by rusticpenn »

titzer wrote: post #41
zaphar wrote: post #24

Earlier quoted context omitted.

Focusing on readability of the code and putting "machine execution" second, means putting the user experience second Nothing kills a users experience like buggy code. Nothing contributes more to buggy code than unreadable or unclear code. This is why another proverb often quoted is "First make it correct, then make it fast". Fast but buggy code will lose to slower but correct code everytime.

> Fast but buggy code will lose to slower but correct code everytime. I wish this were true, but unfortunately C++ proves this is not the case. Fast and buggy seems to be the holy grail there.

because being first to market is much more important than having the perfect tool.

Re: Clear is better than clever [pdf]

#105

Post by coldtea »

jlokier wrote: post #103
deng wrote: post #61

Earlier quoted context omitted.

> Combinations of if/else can seriously damage readability and maintainability. Yes, that's why for selections we usually use switch/case. But of course every programmer worth his money just knows that ?: is right associative and that '&&' is on precedence level 11 while '?:' is on 13. If that's not "clever code", I don't know what is...

> every programmer worth his money just knows that ?: is right associative I would hope every programmer worth their money are very comfortable with it, because chaining like this is a very common syntactic pattern in other people's code: cond1 ? val1 : cond2 ? val2 : cond3 ? val3 : other It is made less readable if you turn it into a right-nested mess of parentheses, so that is rarely seen. Just as nobody thinks of…

>because chaining like this is a very common syntactic pattern in other people's code

If it's very common where you work, then run, don't walk, away...

Re: Clear is better than clever [pdf]

#106

Post by steveklabnik »

saagarjha wrote: post #43
eraxley wrote: post #16

Earlier quoted context omitted.

You are right that (2) needs to be dereferenced first, however, in go a pointer is autmatically dereferenced when accessing its properties or "methods". What I mean by this is that if you want to access a property on thing, it would look the same. In C++ it would look like this: (1) x = thing.Property; (2) x = thing->Property; (or (*thing).Property) but in go, both would look the same, like this: (1) x = thing.Proper…

Rust does this too, I think.

(Yes, it does.)

Re: Clear is better than clever [pdf]

#107

Post by zwkrt »

coldtea wrote: post #96
LandR wrote: post #90

Earlier quoted context omitted.

If someone is hired to work on your code base, presumably they know the language. They know ternarys work... If they don't then they need to learn. You can't say don't use specific language features because some devs can't be bothered to learn them.

> If someone is hired to work on your code base, presumably they know the language. They know ternarys work... It's not whether some constructs are parts of the language (languages can have any crap in), it's whether some constructs are bad, confusing, and should be avoided (whether you know what they do or not).

If people are confused by a ternary statement I don't want them editing code I have to maintain.

Re: Clear is better than clever [pdf]

#108

Post by coldtea »

zwkrt wrote: post #107
coldtea wrote: post #96

Earlier quoted context omitted.

> If someone is hired to work on your code base, presumably they know the language. They know ternarys work... It's not whether some constructs are parts of the language (languages can have any crap in), it's whether some constructs are bad, confusing, and should be avoided (whether you know what they do or not).

If people are confused by a ternary statement I don't want them editing code I have to maintain.

If someone thinks people can't or shouldn't be confused by a ternary statement, then I don't want them editing code I have to maintain either...

Re: Clear is better than clever [pdf]

#109

Post by [deleted] »

zwkrt wrote: post #107
coldtea wrote: post #96

Earlier quoted context omitted.

> If someone is hired to work on your code base, presumably they know the language. They know ternarys work... It's not whether some constructs are parts of the language (languages can have any crap in), it's whether some constructs are bad, confusing, and should be avoided (whether you know what they do or not).

If people are confused by a ternary statement I don't want them editing code I have to maintain.

[deleted]

Re: Clear is better than clever [pdf]

#110

Post by Consultant32452 »

olah_1 wrote: post #33

Sometimes clever means succinct. And maintaining less lines of code can also lead to less bugs.

I'm not disagreeing with you, and maybe this is just my personal experience, but there seems to be a movement that promotes succinctness over all other qualifications. It's as if someone's comp-sci class had a competition for who could accomplish some task with the fewest bytes of code and a whole generation of programmers never got out of that mode.

I've heard comedians talk about a set not having any fat in it... every phrase, every short pause, etc. is exactly what is needed to make the bit funny. To stretch this analogy a bit, you can trim so much fat that you start taking the meat and the audience can no longer follow the joke. We need that kind of philosophy in coding.

Post reply on HN