Live data from Hacker News

Clear is better than clever [pdf]

dave.cheney.net

331–335 of 335 posts

Re: Clear is better than clever [pdf]

#331

Earlier quoted context omitted.

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 ne…

Very lispy :-) Some would say top-level blocks returning the last value in the block is an anti-pattern, because functions which aren't meant to return a value end up leaking the value of the last thing called in the function, which might be another function, which called another function. Or it might be in various branches of an 'if', which aren't being examined for being an acceptable return value. Perl does this,…

> like ecmascript's "do"

Keep in mind this is only a stage 0 proposal, and thus is not really part of the language. This is how statements behave when entered into the repl, e.g. the browser dev console.

Re: Clear is better than clever [pdf]

#332
post #218

Earlier quoted context omitted.

"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…

In Python you can write it like this: if a b: x = 1 else: x = 0 Which a lot of people seem to hate for some reason, but I always appreciated the compromise between terseness and clarity.

Python uses the `elif` keyword if you want to place an `else if` on one line. And column indentation isn't very "pythonic", apparently.

Re: Clear is better than clever [pdf]

#333

Earlier quoted context omitted.

> You see the problem though, I need to try it and practice it to see how simple and clear it is. You need to practice it to overcome your skepticism resulting from your ingrained habits that prejudice you against it, not because it's inherently unreadable. It literally takes 5 seconds to understand the idiom: conditions/guards on the left, value on the right. It's essentially a truth table. > Why do I want that? To…

>It literally takes 5 seconds to understand the idiom I understand how ternary operators work. It's still hard to read if you inline multiple ternary operators the way OP suggested is easy. It adds cognitive complexity, and hides bugs because your brain will fill the details on what it assumes it does, versus the subtleties of what it actually does. In fact, it is obviously so confusing that to make it work someone s…

But those two pieces of code are parsed exactly the same way in most languages--the only difference is the newline between `else` and `if`

Re: Clear is better than clever [pdf]

#334
post #189

Earlier quoted context omitted.

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…

You assigned “myVar” in every branch, right? Let me reread that again to make sure you really are assigning myVar in every case. That’s a problem. One I’ve seen all too often, but a problem, nonetheless.

As I mention above, it "degenerates" better in that if more code is needed in each sub-block, it's easy to add. I'm okay with syntax that could factor such out if it doesn't require overhauling the block when the starting simple pattern goes away over time. As they say, the wrong abstraction is often worse than no abstraction. Change can kick the simple pattern away.

Re: Clear is better than clever [pdf]

#335

Earlier quoted context omitted.

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 ne…

Very lispy :-) Some would say top-level blocks returning the last value in the block is an anti-pattern, because functions which aren't meant to return a value end up leaking the value of the last thing called in the function, which might be another function, which called another function. Or it might be in various branches of an 'if', which aren't being examined for being an acceptable return value. Perl does this,…

Perl6 has remedied the accidental leak of values to the caller by allowing you to give a return value in the signature.

This will ignore the last result and return Nil instead:

    sub foo ( $_ --> Nil ) {…}
This only works with literals, constants and Nil.

If you specify a type instead, it only enforces that the result is of that type.

Post reply on HN