171–180 of 601 posts
Early returns only work well in untyped, statement oriented languages, like JavaScript. I'd rather change the language.
In Ruby these are idiomatic enough to have a name and are built into the linter, so it'll yell at you if it sees that you're not using guard clauses. As a further refinement, I will often take tricky conditional logic and put them into a method that consists of nothing but guard clauses and a return true or false at the bottom of the method. In Ruby you can use ? and ! at the end of method names, so I'll give the met…
I would love Ruby-style guard clauses in JavaScript. Sometimes I wish I’d never written anything in Ruby just so I’d stop thinking about how great it would be if other languages shared some of its features.
Earlier quoted context omitted.
> Same way comments are extra weight that should only be in public or algorithm/need to know areas. Unless you are writing completely brilliant code your future self will hate you if you skimp on comments. Also self-documenting code is great, but intentions are not always clear to another person trying to figure out your code.
Comments that answer "what" are redundant. Choose your identifiers better. Write good commit messages and comments that answer "why" are redundant too. Commit messages by their nature refer to the exact code that they refered to when they were written. Comments answering "why" after a few years are misleading anyway, because code changed around them. Commenting public api etc is obvious, and most people do it.
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/LanguageE...
Programmers with lots of hours of maintaining code eventually evolve to return early, sorting exit conditions at top and meat of the methods at the bottom. Same way you evolve out of one liners. Same way comments are extra weight that should only be in public or algorithm/need to know areas. Same way braces go on the end of the method/class name to reduce LOC. Same way you move on from heavy OO to dicts/lists. Same w…
> Same way braces go on the end of the method/class name to reduce LOC. Screw that. I've been writing code for 15 years, and Allman style braces make it so much easier to mentally parse code into blocks that they're worth every single LOC. I can't speak for anyone else but I'm not working on an 80x24 terminal anymore.
As everyone else seems to use K&R I've just had a adapt over time :-(
Programmers with lots of hours of maintaining code eventually evolve to return early, sorting exit conditions at top and meat of the methods at the bottom. Same way you evolve out of one liners. Same way comments are extra weight that should only be in public or algorithm/need to know areas. Same way braces go on the end of the method/class name to reduce LOC. Same way you move on from heavy OO to dicts/lists. Same w…
" Best thing I learned about commenting is: Comment WHY you are doing it... not WHAT. Code is the WHAT... Comment is the WHY
Earlier quoted context omitted.
> Same way comments are extra weight that should only be in public or algorithm/need to know areas. Unless you are writing completely brilliant code your future self will hate you if you skimp on comments. Also self-documenting code is great, but intentions are not always clear to another person trying to figure out your code.
Only "brilliant" code ends up needing comments. Plain code organized into understandable methods (usually no more than half a page of code), with good naming for variables & method names reduces the need for comments. It's also easier to scan/read code if there's a minimum of comments in the way.
Code shows what is being done. Comments should explain why it's being done.
Programmers with lots of hours of maintaining code eventually evolve to return early, sorting exit conditions at top and meat of the methods at the bottom. Same way you evolve out of one liners. Same way comments are extra weight that should only be in public or algorithm/need to know areas. Same way braces go on the end of the method/class name to reduce LOC. Same way you move on from heavy OO to dicts/lists. Same w…
> Same way braces go on the end of the method/class name to reduce LOC. Screw that. I've been writing code for 15 years, and Allman style braces make it so much easier to mentally parse code into blocks that they're worth every single LOC. I can't speak for anyone else but I'm not working on an 80x24 terminal anymore.
A more formal name for this approach is / could be Guard Clauses: https://refactoring.com/catalog/replaceNestedConditionalWith... . This pattern has been elevated to a language construct in Swift: https://thatthinginswift.com/guard-statement-swift/
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 inst…