3 ms·
I am personally a fan of a single return statement. Abolishing intend and else branches may be nicer to read but it hides cyclomatic complexity. A complexity wh
by oaiey 6y ago
I am personally a fan of a single return statement. Abolishing intend and else branches may be nicer to read but it hides cyclomatic complexity. A complexity which will not vanish but is no longer visible.
- 100011_100001 6y agoI would like to postulate that having an else makes it easier to read. We think in if/else fuzzy scenarios, it's why it flows so well in code. If you were teaching someone about traffic lights you would verbally explain something like this: if (light == green) { go() } else { stop() } Not this: if (light != green) { stop() } go() ...and we haven't handled what to do when the light is orange. Edit: In total agreement about the the single return, which is why I ignored that part of your post.
- rory 6y agoPersonally, I find it easier to parse if the conditional is not only exhaustive, but itself returns a value (functional languages like Ocaml, Scala, Elixir have this). Judging by the number of long, goofy-looking nested ternary expressions I find in Javascript code, a lot of people feel this way.
- oaiey 6y agoIn functional programming everything is essentially an expression. So coming from there to procedural programming will create patterns like that or ternary expressions. I come from a pascal/assembler school of thinking which is favoured in the OO/procedural languages. So when a language is using a procedural sytax then I code also in that style.