Live data from Hacker News

Clear is better than clever [pdf]

dave.cheney.net

131–140 of 335 posts

Re: Clear is better than clever [pdf]

#131
post #116

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…

As long as verbosity is meant to make your code more explicit I'm fine with it. Personally, I find that ternary example you posted to be terrible code. We are not using parchment anymore, there is nothing to be gained by saving a couple of lines.

I disagree, what is "saved" is your time when reading/understanding... why spend time to read 10 lines and figure out that it actually does what a simple ternary operation would accomplish??

On that same vein, if a ternary operation is going to throw someone for a loop, I've got some bad news about their career in programming.

Re: Clear is better than clever [pdf]

#132

Earlier quoted context omitted.

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…

Or it could be that it’s subjective and there is no truly objective answer.

Re: Clear is better than clever [pdf]

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

Nothing kills a users experience like buggy code. [..]Fast but buggy code will lose to slower but correct code everytime. Remind me how Chrome took over the browser market with "Chrome Fast" as its slogan? How did nginx grow so popular against Apache? Was it promoted as "less buggy" or "faster"? How MySQL became so prominent, was that people choosing "slower but more correct"? How MongoDB became so popular - "slower…

     Ten characters of unreadable code written by an expert 
     will have fewer bugs than 100,000 lines of "readable, 
     clear" C++ code written by a novice.
Everytime this topic comes up someone brings up this point. The counter to it is always the same. In the lifetime of those ten characters someone who is not the original author will have to modify it. Because it is not clear what exactly the code is doing they will probably introduce a subtle bug. Iterate on that a few times and eventually you will have code that literally no one can safely touch and the only way to fix it will be to rewrite it.

If the person doing the rewrite is smart and looks at why the rewrite was necessary they will change those "ten characters" to however many it takes to make it understandable for the future maintainer. It should be exactly as short as necessary to be clearly correct and no shorter. Then you can work at making it faster with appropriate comments about why this particular speed hack is necessary and what you need to know before you modify it.

Re: Clear is better than clever [pdf]

#134
post #113

Earlier quoted context omitted.

Ternary isn't the same as a branch and you want your this simple comparison function to get inlined every time

> Ternary isn't the same as a branch It should be. The C ternary is just an expression-oriented version of if/elseif/else. Languages with a functional bend simply make if/elseif/else an expression in the first place e.g. in Rust it'd be return if a b { Ordering::Greater } else { Ordering::Equal } Though obviously that specific version is an overly complex way of writing: return a.cmp(b);

Most compilers will probably reduce if-else and ternary to the same instructions. If it's a conditional value binding it might not be a branch but a conditional move instruction.

Re: Clear is better than clever [pdf]

#135
post #55

Earlier quoted context omitted.

Maybe you'll prefer return (a b) ? 1 : // a greater 0; // equal

What's the point? Why not just make it an if-elseif-else block and make it obvious?

Nested ternary is obvious when formatted as above, and it's dramatically more compact. Try it for a bit, you'll see how simple and clear it is.

Re: Clear is better than clever [pdf]

#136
post #116

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…

As long as verbosity is meant to make your code more explicit I'm fine with it. Personally, I find that ternary example you posted to be terrible code. We are not using parchment anymore, there is nothing to be gained by saving a couple of lines.

> We are not using parchment anymore, there is nothing to be gained by saving a couple of lines.

This is not what the OP is talking about - we are not using parchment anymore, but we still have the same brains, being able to fit more code in our head with less i/o allows is a more holistic view.

There is a balance in between terse and verbose that produces a reasonable length of code for what it is doing, and that is subjective, to the individual and the code - so you are never going to agree on everything. But I say fuck no to people who want to lower everything to the common denominator, that is mediocrity, I don't want my grandma to be able to read the code if it makes macro comprehension horrible to the point of making it unmaintainable spaghetti.

Re: Clear is better than clever [pdf]

#137

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…

That is extremely hard to read, at least without parentheses to show where to split the expressions at a glance.

Re: Clear is better than clever [pdf]

#138
post #116

Earlier quoted context omitted.

As long as verbosity is meant to make your code more explicit I'm fine with it. Personally, I find that ternary example you posted to be terrible code. We are not using parchment anymore, there is nothing to be gained by saving a couple of lines.

I disagree, what is "saved" is your time when reading/understanding... why spend time to read 10 lines and figure out that it actually does what a simple ternary operation would accomplish?? On that same vein, if a ternary operation is going to throw someone for a loop, I've got some bad news about their career in programming.

These are both extremes and both bad. The 10 line switch statement to switch a variable is a high cognitive load for no good reason but so is a nested ternary under pretty much any circumstances, but especially with single character variables and magic numbers.

>On that same vein, if a ternary operation is going to throw someone for a loop, I've got some bad news about their career in programming.

You're right about someone having and issue if they can't understand this on it's own. What was the last application you worked in where that single line is all you had to understand to accomplish whatever task you were working on?

Re: Clear is better than clever [pdf]

#139
post #116

Earlier quoted context omitted.

As long as verbosity is meant to make your code more explicit I'm fine with it. Personally, I find that ternary example you posted to be terrible code. We are not using parchment anymore, there is nothing to be gained by saving a couple of lines.

I disagree, what is "saved" is your time when reading/understanding... why spend time to read 10 lines and figure out that it actually does what a simple ternary operation would accomplish?? On that same vein, if a ternary operation is going to throw someone for a loop, I've got some bad news about their career in programming.

> why spend time to read 10 lines and figure out that it actually does what a simple ternary operation would accomplish??

Because when something is expressed in 10 lines explicitly, generally you can simply skim over the code to get an idea of what's going on without having to go into the details.

"Smart and clever" code, like using nested ternaries, demands you to focus and try to figure out what is going on.

Re: Clear is better than clever [pdf]

#140
post #39

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…

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…

I usually write if in such cases.

Or sometimes for multiple condition branches I use bitwise operators to create integer bit mask with couple of bits, then switch(), or array indexer, with all possible 4-8-16 values.

Your version is more error prone because contains more code than necessary. Note how it’s just “else” in original version, and manual negate statement, (cond2) && (!cond3), in your version. Easy to screw up when modifying the code at some later point. When you then need to replace cond3 with cond4, forget about second branch and the algorithm will break.

Post reply on HN