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

231–240 of 335 posts

Re: Clear is better than clever [pdf]

#231

Post by kazinator »

atq2119 wrote: post #217
kazinator wrote: post #214

Earlier quoted context omitted.

I don't agree. It occludes the nested structure. We can regard the condition as the head of a clause, and the ? and : as heads of sub-clauses: A ? B : C which leads to: return a b ? 1 : 0;

What you're writing here is equivalent to insisting that people do: if (a b) { return 1; } else { return 0; } }

Nope, since I haven't added any non-whitespace characters, rather it is like insisting that people do:

  if (a  b) {
      return 1;
    } else {
      return 0;
    }
Unlike your perfectly formatted code there, this has a bit of a visual problem: a one-liner consequent is fully braced, whereas a multi-line alternative isn't.

Ternary operators are different. They have confusing nesting and do not support the equivalent of the "if/else ladder" pattern very well.

Re: Clear is better than clever [pdf]

#232

Post by macspoofing »

verall wrote: post #113
macspoofing wrote: post #60

Earlier quoted context omitted.

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

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

If you need to optimize to that extent, then do whatever you need to do. In the vast majority of applications it makes no difference.

Re: Clear is better than clever [pdf]

#233

Post by [deleted] »

tabtab wrote: post #189
hotBacteria wrote: post #65

Earlier quoted context omitted.

You can write it without resorting to one-line conditionals: if(cond1){ myVar = 1; } else if(cond2 && cond3){ myVar = 10; } else if(cond2 && !cond3){ myVar = 100; } else { myVar = 4; } But when I encounter this kind of situations I have other problems than code formatting anyway: with 3 conditions you have 2^3 possibilities to check: are you really really sure (!cond1 && !cond2 && cond3) should give you defaultValue…

That makes code formatting inconsistent because many prefer the other way. The VB.Net style is more compact and readable in my opinion: if cond1 then myVar = 1 else if cond2 and cond3 then myVar = 10 else if cond2 and not cond3 then myVar = 100 else myVar = 4 end if The VB.Net style also makes it easier to identify mismatched blocks because the "enders" are named differently. (One can also put the assignment on the s…

[deleted]

Re: Clear is better than clever [pdf]

#234

Post by kazinator »

0xffff2 wrote: post #226
kazinator wrote: post #209

Using the keyword switch for successive condition testing is a travesty. Switching means taking one of several code paths based on a value. The problem with using a switch syntactic sugar for conditional testing is that the cases are not exclusive: switch { a > 5: ... a > 3: ... } Here a > 3 is not reachable: it tests a condition that overlaps with a > 5 completely, and a > 5 is earlier. This form of switch would be…

Either my minimal understanding of Go is showing, or this just proves your point, but don't you have your conditions backwards? `a == 4` would fail the `a > 5` condition and so execute the `a > 3` case, right?

Yes, I should have a > 3 first, since I was trying to say that the values of a that would trigger a > 5 are caught by a > 3. If a clause is obviously unreachable, that's likely a bug. But it doesn't mean that reversing the clauses is the right fix, either. They continue to overlap; and if that is allowed, this is not a "switch" in any sense.

Re: Clear is better than clever [pdf]

#235

Post by macspoofing »

naasking wrote: post #135
macspoofing wrote: post #60

Earlier quoted context omitted.

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.

You see the problem though, I need to try it and practice it to see how simple and clear it is. I can write code that I can easily understand. I can write terse, clever code that I can easily understand. But I want to write code so that the next person can also easily understand it. More importantly, code that's easier to understand has less chance of getting buggy when it inevitably gets rfactored or extended.

>and it's dramatically more compact

Why do I want that?

Re: Clear is better than clever [pdf]

#236

Post by zaphar »

jodrellblank wrote: post #181
zaphar wrote: post #133

Earlier quoted context omitted.

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…

You want a large amount of code, because you're afraid of maybe having to rewrite a small amount of code? How does that make sense, and why won't the large amount go through the same iterative adjustment and subtle bugs until it needs rewriting? Because it is not clear what exactly the code is doing A ten character English which name vaguely describes what a function hidden in another file might have been doing (assu…

It's not about the length of the code. It's about how understandable it is. I think we are talking past each other so I'll bow out now. We can agree to disagree.

Re: Clear is better than clever [pdf]

#237

Post by munchbunny »

macspoofing wrote: post #235
naasking wrote: post #135

Earlier quoted context omitted.

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.

You see the problem though, I need to try it and practice it to see how simple and clear it is. I can write code that I can easily understand. I can write terse, clever code that I can easily understand. But I want to write code so that the next person can also easily understand it. More importantly, code that's easier to understand has less chance of getting buggy when it inevitably gets rfactored or extended. >and…

Compactness and readability are related, in the sense that your working memory also works somewhat in terms of lines of code.

There's a natural trade-off in the sense that in order to make something more compact, you have to rely on the context to provide whatever information you remove. For example, the ternary pattern of chaining ?:'s. You have to be used to it. However, once you know it, the more compact pattern works fairly well.

Re: Clear is better than clever [pdf]

#238

Post by rbavocadotree »

MaxBarraclough wrote: post #220
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…

I guess I'm in a minority here, but I wish more non-functional languages would feature pattern matching, of the sort seen in Haskell and OCaml. [0] This language-design question is essentially a solved problem, but few new languages (outside the pure-ish functional ones) make the effort. Trivial example in OCaml: let imply v = match v with (true,x) -> x | (false,x) -> true;; [0] https://caml.inria.fr/pub/docs/oreilly…

It's becoming more popular. Kotlin, Swift and now C# 8.0 have pattern matching (well, close enough at least). I sure hope other languages take note, because you are right about it essentially being a solved problem.

Re: Clear is better than clever [pdf]

#239

Post by bryanrasmussen »

whatshisface wrote: post #115
bryanrasmussen wrote: post #112

Earlier quoted context omitted.

how many branches/how much depth in a ternary statement would you consider to be too many/too much? Is there never going to be any level of depth in a ternary statement which you will think is perhaps too great, and want to switch to some more verbose syntax?

A lisper would say that there is absolutely no limit, and that in fact all programs should be structured like that.

That's not what it looks like to me https://yoo2080.wordpress.com/2014/07/04/it-is-not-hard-to-r...

Re: Clear is better than clever [pdf]

#240

Post by josephg »

mayoff wrote: post #206
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…

This came up recently on the Swift Evolution forum (which is the official forum for discussing changes to the Swift programming language). Dave Abrahams said, “[…] I keep meeting experienced programmers (really smart people!) that have no trouble reading [a chain of if/else statements] and yet are confused by the analogous ternary construction: [a chain of ?: expressions]”. https://forums.swift.org/t/pitch-if-else-ex…

My favourite solution to this problem is how rust does it. In rust every block can evaluate to an expression, so if/else is the ternary operator.

    let x =
      if cond1 { expr1 }
      else if cond2 && cond3 { expr2 }
      else { expr3 };
It’s more verbose this way (‘?’ Vs ‘else if’) but there’s no question of readability because it’s just if/else. You can format it however you like, and add statements into the blocks later if you need to, too.

Rust also has the match statement, which is cleaner whenever your conditions are mutually exclusive.

Post reply on HN