3 ms·

This seems indicative of the arrow anti-pattern[1] and guard clauses[2][3] would be preferable to banning null and cluttering your class definitions with isDefi

by ihsw 14y ago

This seems indicative of the arrow anti-pattern[1] and guard clauses[2][3] would be preferable to banning null and cluttering your class definitions with isDefined everywhere. [1] http://www.codinghorror.com/blog/2006/01/flattening-arrow-code.html http://www.codinghorror.com/blog/2006/01/flattening-arrow-co... [2] http://martinfowler.com/refactoring/catalog/replaceNestedConditionalWithGuardClauses.html http://martinfowler.com/refactoring/catalog/replaceNestedCon... [3] http://c2.com/cgi/wiki?GuardClause http://c2.com/cgi/wiki?GuardClause The most important point: handle negative conditions first, so checking for null first and putting a return statement right away when detected.

tikhonj 14y ago
You should look at the second part of the blog post[1]. It shows how to get around the "arrow anti-pattern" using map, filter, flatMap and for-comprehensions in Scala. It's actually both simple and elegant! Also not very hard to understand. [1]: https://blog.stackmob.com/2013/01/free-yourself-from-the-tyranny-of-null-part-2-why-weve-banned-null-in-our-codebase/ https://blog.stackmob.com/2013/01/free-yourself-from-the-tyr... What you're actually doing is using the Option monad in Scala, but the article doesn't tell you that to avoid scaring you. And it succeeds: the pattern described in the second part of the blog post is easy to follow and clearly has no magic.