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

171–180 of 335 posts

Re: Clear is better than clever [pdf]

#171

Post by java-man »

edejong wrote: post #166
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 find it interesting to see so much emphasis on small syntax nit-picking while totally forgetting the large scale question. Although I've used a ternary operator or 'if' statement from time to time, in general I would like to model the boundrary conditions themselves and separate condition and action (reduces coupling and enhances the possibility of reporting what is going on). In your case, the a intList.sort(IntOr…

this is one of the most informative and clear response for this topic. thank you very much!

Re: Clear is better than clever [pdf]

#172

Post by masklinn »

bryanrasmussen wrote: post #114
jodrellblank wrote: post #87

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…

I once had to maintain a chat app in which the first developer had written something like the following at some point: if (statement = ref) { print(statement) } else { print('have you done everything right?') } was I wrong to be confused as to what he might have intended with statement = ref? Because he was in fact using the language functionalities to express what he wanted. I just thought it looked confusing and mi…

FWIW modern C compilers recommend double-bracing exactly for that reason e.g. in clang, by default, it triggers:

    test.c:3:17: warning: using the result of an assignment as a condition without parentheses [-Wparentheses]
      if (statement = ref) {
          ~~~~~~~~~~^~~~~
    test.c:3:17: note: place parentheses around the assignment to silence this warning
      if (statement = ref) {
                    ^
          (              )
    test.c:3:17: note: use '==' to turn this assignment into an equality comparison
      if (statement = ref) {
                    ^
                    ==

Re: Clear is better than clever [pdf]

#173

Post by deng »

illys wrote: post #81
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...

Never thought the ternary operator required high expertise for associativity/precedence reasons and could sentence me to "clever code"... Besides switch/case do not apply to a mix of true/false conditions but to the different values of a single variable. Funny :-) Thanks.

> Never thought the ternary operator required high expertise for associativity/precedence reasons

If you chain or nest them.

> Funny :-)

I'm glad I could brighten your day a little bit.

Re: Clear is better than clever [pdf]

#174

Post by uryga »

jimbokun wrote: post #162
pier25 wrote: 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.

"Personally, I find that ternary example you posted to be terrible code." It's not about the line count, it's about expressing the main idea clearly and succinctly, which this code does. My nitpick would be with the language constructs themselves. The ternary operator is simply a crutch for lack of an if-then expression returning a value. if a b then 1 else 0 Or can add some white space to make the structure a little…

it's also nice with Haskell's Multiway If:

  x = if | a  -1
         | a > b     ->  1
         | otherwise ->  0
(and `cond` in lisps)

Re: Clear is better than clever [pdf]

#175

Post by ergothus »

coldtea wrote: post #105
jlokier wrote: post #103

Earlier quoted context omitted.

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

"readability" is largely a matter of familiarity, so it's very hard to make such sweeping statements accurately. The difference between "common idiom" and "unreadable mess" is "common", not the code itself.

Re: Clear is better than clever [pdf]

#176

Post by humblebee »

eternalban wrote: post #22

"When declaring and initializing do ...". Thank you Dave but some of us prefer explicit 'vars' all the time and reserve := for quickie peripheral variables.

Do you have some examples of this style in go? This was once a gripe of mine with go, but I have since just gotten use to the lack of clarity around types I'm working with.

I came from JavaScript so it wasn't too hard, but I was writing mostly with C when I first encounter go. With JavaScript I heavily leaned on properly named variables to understand the underlying type within the context of the code I was working on. In go however, short and nondestructive variables are common place, with the lack of types in declarations I have to reply on properly named functions and general context of the code I'm working in.

I'd be curious to see what go looks like with explicit vars for most things.

Re: Clear is better than clever [pdf]

#177

Post by edejong »

java-man wrote: post #171
edejong wrote: post #166

Earlier quoted context omitted.

I find it interesting to see so much emphasis on small syntax nit-picking while totally forgetting the large scale question. Although I've used a ternary operator or 'if' statement from time to time, in general I would like to model the boundrary conditions themselves and separate condition and action (reduces coupling and enhances the possibility of reporting what is going on). In your case, the a intList.sort(IntOr…

this is one of the most informative and clear response for this topic. thank you very much!

Thanks for replying. So many words but not sure whether the message came across.

Re: Clear is better than clever [pdf]

#178

Post by Schattenbaer »

illys wrote: post #39
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…

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 have also seen switch statements used (abused?) to do a similar thing. Since a switch executes the first statement that is equivalent to the control expression you can pass true as the control expression, e.g.:

  switch(true) {
    cond1: return 1;
    cond2 && cond3: return 10;
    //etc
  }
Not sure I'd recommend it but it works in a few languages :)

Elixir has cond that does this nicely without resorting to strange switch statements:

https://elixir-lang.org/getting-started/case-cond-and-if.htm...

Re: Clear is better than clever [pdf]

#179

Post by buu700 »

revvx wrote: post #159
buu700 wrote: post #88

I agree with the sentiment, but not with Go's interpretation. To me, higher-order functions like map and reduce are much easier to read than the equivalent for loops and are less likely to have subtle bugs (off-by-one errors, etc.) because they more directly capture the author's intent.

I agree 100%. In my experience, loops and recursion are lower level constructs that should ideally be used only in libraries (map, filter, limit, sum, distinct, etc [1]) and in hot code paths (for optimization). Kevlin Henney makes a good observation on one of his talks about how "you have written all the loops you will never need in your life" [2], and those are constructs such as map/filterand friends, present in L…

I have mixed feelings about "Reduce". It is hard to use and, most of the time, hard to read as well. It's too low-level.

Fair enough. I'd certainly always prefer a special case like `.sum()` over something like `.reduce((a, b) => a + b, 0)` where applicable.

I don't think reduce is overly complicated, but it's not much of a step up over a for loop and can be abused to write code that's more confusing to reason about than an equivalent loop.

Re: Clear is better than clever [pdf]

#180

Post by JJMcJ »

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…

Parentheses would help make the one liner simpler but your basic point seems quite accurate.

In the end, what's simpler, spending 15 seconds looking at a one liner using well known language syntax, or digging through half a screen of if states, for loops (use iterators instead), for two examples.

Post reply on HN