5 ms·
It depends! But it depends on the actual meaning of the code, so examples which use meaningless identifiers like `doStuff()` miss the distinction. If the condi
by olavk 9y ago
It depends! But it depends on the actual meaning of the code, so examples which use meaningless identifiers like `doStuff()` miss the distinction.
If the conditions are semantically symmetrical, if/else is the right approach:
fun max(a, b) {
if a > b { a } else { b }
}
But is it a precondition which causes you to skip the primary logic of the function, then get it out of the way early:
fun max(a, b) {
// special case for null
if a==null or b==null { null }
if a > b { a } else { b }
}
Yeah we want to reduce indentation, but not at the cost of making the code overall harder to follow. The logic of "max" is much clearly expressed as a single expression with `else`.
- garganzol 9y agoExactly this. Anyone who put their shoe in functional programming can make such a distinction. Early returns are not a panacea. If/Else-everything is not a silver bullet either.
- ngvrnd 9y agoHow about "there are no silver bullets, there is no substitute for clear thinking."
- Hendrikto 9y agoYou could still write it as fun max(a, b) { if a > b { return a } return b } Not saying this is necessarily better or worse. The point I want to make is that your case isn’t special.
- olavk 9y agoI am arguing this is worse, since it expresses the logic in a more convoluted way.
- arghwhat 9y agoI would argue that it is by no means more convoluted. It is quite clear and concise. All of the following are equally readable: if (x > y) { return x; } else { return y; } if (x > y) { return x; } return y; return (x > y) ? x : y; The logic would be convoluted if you are going through extra hoops in order to write your logic like this, making the flow of the application unclear. For some things, an else branch ends up just being easier to deal with. This is especially true in languages like Rust, where if/else is an expression, leading to the following construct being used often (although usually with more complicated content): let max = if (x > y) { x } else { y }; Note that "max" is immutable despite the conditional assignment due to the if being used as an expression.
- foobarchu 9y agoI think it's only clear and concise looking because of the achilles heel of this entire thread: terse examples. As soon as you need to do more than a single line of work, the else'd version becomes far more readable (due to superior indentation and clearer guarantees of what happens when). If it's a single line of return in both branches, then a ternary expression is usually going to be ideal instead.
- arghwhat 9y agoWe can definitely agree that the examples are too simple to present any readability issues with any method of writing them short of an IOCCC entry. I do not agree with the conclusions you draw at all, but it is hard to continue the discussion without examples. There are definitely cases where an else clause is the natural choice, but I believe that these are in the minority.
- jehlakj 9y agoIf you’ve ever had to deal with various errors or to filter out something and return the appropriate output, it is much more concise. Read past the if’s and you have the main logic of that function. But that max function should have an else statement since it's part of the logic. Less code doesn't always make it more concise. If there's a more complicated logic, then it'd actually be harder to understand at a glance.
- dragonwriter 9y agoThe earlier version is clearly better and more clear, but presumes a language where if is an expression (and the actual return keyword isn't required, though “return if ...” is nearly as good.) But if you are using a more imperative language where “if” is a statement, I think the merits of early return vs. use of an else clause are more balanced in this case.
- olavk 9y agoIn C style languages you have the ?: operator though, which is basically if as an expression.
- dragonwriter 9y agoFunctionally, yes, in terms of readability, not really. But, yes, for really simple cases like the example under discussion: return (a>=b) ? a : b is probably the best option in those languages. The level of complexity at which the C ternary operator ceases to be ideal, I think, is lower than that of expression-if.
- timoxley 9y agoYeah no hard rules, agreed on this point, especially when the if/else body is short.
- icc97 9y agoThe pre-conditions are called Guard Clauses [0]. It's really useful to think about guard clauses and explicitly look for them to ensure the pre-conditions are met rather than have them appear over time as if/else blocks. edit: now that I've looked through the comments I see these are mentioned on numerous other threads. [0]: https://en.wikipedia.org/wiki/Guard_%28computer_science%29 https://en.wikipedia.org/wiki/Guard_%28computer_science%29