3 ms·
There are major issues with not using else - in that there is no obvious way to test whether it should be there or not. Any programmer returning to your code (
by louthy 9y ago
There are major issues with not using else - in that there is no obvious way to test whether it should be there or not. Any programmer returning to your code (or even you returning to your code a year later) can't know what the intention was/should be, and neither can the compiler.
I try (in C#) to avoid if/else completely (not always possible, but it's a general guide) and I try to work with ternary expressions instead. This forces you to explicitly consider the else case and explicitly state what the intention was. It also makes composition of code blocks simpler and often removes the issues of statement ordering.
You can take it further by using Option\Either\Validation monads to reduce the cyclomatic complexity [1]. This approach can allow for composable and reusable validation computations making the job of validation trivial.
By the way, this is more of a general point about if/else rather than the very simple case of argument validation that the blog talks about. I don't particularly have a major issue with a series of early outs in any function. But if you want to do anything more complex, ignoring else can be a source of bugs.
[1] https://github.com/louthy/language-ext/blob/master/LanguageExt.Tests/ValidationTests.cs#L140 https://github.com/louthy/language-ext/blob/master/LanguageE...
- seanmcdirmid 9y agoYou aren’t really reducing complexity with the monadic approach, just replacing explicit control flow for implicit control flow masked as data flow. Debugging can become harder in the latter case.
- louthy 9y agoWhich is written once, rather than 1000s of times. That's a reduction in cognitive load and the same 'missing else' bugs I mentioned. I agree it's not always easier to debug - but mostly (I find) writing code as pure expressions rather than a sequence of statements reduces the need for debugging massively. So, I don't think it's quite as black and white as you paint.
- seanmcdirmid 9y agoNo, you usually have to debug just as much, you just don't have any nice tools to do it with. I agree the monadic approach looks cleaner, but just be ready to undo it for any kind of hairy logic that requires debugging.
- louthy 9y agoI have not found that and use it extensively. So, I respectfully disagree. Debugging isn’t significantly harder, it’s a bit harder. In VS you can break on individual LINQ expression stages, read the unpacked values, read the let values, etc. If I’m composing with Bind functions then I can always break either inside the lambda or the static function being used for the bind operation.
- seanmcdirmid 9y agoYou can eval the arguments, but you still have to pop a stack frame on if you can at all to get at the underlying control flow. You then have to integrate all those frames by yourself in your head. Even the most ideological Scala programmer wouldn’t replace all their if statements with options.