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

71–80 of 335 posts

Re: Clear is better than clever [pdf]

#71

Post by pekim »

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…

   return a  b ? 1 : 0;
That's a nice approach. However the document is about Go, and Go doesn't have a ternary operator. So that probably leaves the switch solution as the clearest one.

Re: Clear is better than clever [pdf]

#72

Post by brmgb »

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.

Re: Clear is better than clever [pdf]

#74

Post by yiyus »

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…

(a>b)-(a<b)

Re: Clear is better than clever [pdf]

#76

Post by jodrellblank »

zaphar wrote: post #24
jodrellblank wrote: post #18

Programs must be written for people to read, and only incidentally for machines to execute. –Hal Abelson and Gerald Sussman Often quoted, and I wonder if there's much evidence supporting it? Let's replace "machines execute it" with "people use it without reading the source code", and we can say that code is run many many more times than it is read. Focusing on readability of the code and putting "machine execution" s…

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 but more correct" winning out?

Cite some instances of when "slower but more correct" has ever won out, assuming the faster system does work?

Nothing contributes more to buggy code than unreadable or unclear code.

That's quite likely false. 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.

Nothing contributes more to buggy code than simply more code. To quote Arthur Whitney: "The only program which stands a chance of being correct is a short one."

Re: Clear is better than clever [pdf]

#77

Post by ptero »

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…

In my experience, verbosity is a slight detriment to clarity -- concise code tends to be easier to understand, although the relationship is not very strong and there are many counterexamples.

The key to clarity and maintainability for me, though, is in the structure. If the code is structured in manageable blocks with clear description on what each block does and how blocks fit together I care little whether within each function the code is concise or verbose.

As a data point, in larger projects with good structure, I generally saw more use concise code than verbose, which may account for my original "concise is better" bias. Just my 2c.

Re: Clear is better than clever [pdf]

#78

Post by _bxg1 »

Random_Person wrote: post #70
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 couldn't disagree more. Nested ternarys are NEVER okay. They are confusing and misleading to anyone new to your code base.

I would make the exception that if you judiciously indent then across multiple lines, to reflect the nested structure the way the if/else equivalent would, then they're fine. But yeah, nested ternaries on one line are impossible to follow.

Re: Clear is better than clever [pdf]

#79

Post by jlokier »

Random_Person wrote: post #70
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 couldn't disagree more. Nested ternarys are NEVER okay. They are confusing and misleading to anyone new to your code base.

I wouldn't call that example nested; I'd call it sequentially chained, and I think that pattern is quite clear even with many conditions in the sequence.

That pattern is the expression equivalent of if..; elsif..; elsif..; elsif...

Writing it out in long form using actual if statements doesn't add much clarity, and costs in verbosity, as the OP says, macro-clarity versus micro-clarity.

I agree with the sibling to this comment, though, that a ternary is more readable with newlines and indentation:

  return (a  b ? 1
          : 0);
That's the style I use, except for extremely short and ternaries where the verbosity adds nothing, like (A > B ? A : B).

In my view it becomes more complex to understand when there's a ternary inside the first branch, because then it's equivalent to if...(if...else...)...else... At that point I'd consider using if statements, if there is no reason to stay with an expression.

Re: Clear is better than clever [pdf]

#80

Post by oumua_don17 »

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 always found CL's `cold` macro very readable to use instead:

```

(cond ((

      ((> a b) -1)

      (t 0))
```

edit 1: formatting

Post reply on HN