Find it hard to shake of the Java-isms? Here’s a little inspection and quick fix to help out when you redundantly use `return`.
After the quick fix is applied:
What other anti-patterns do you notice in code written by recent converts from Java? Pattern Matching on booleans? Overuse of Option#isDefined? Providing inspections for these can help keep code clean and educate the programmer; we’re interested in what you thing is important.
I’d love to have Option usage spelled out more clearly. There are any number of times I’ve done
optionFoo match {
case Some(foo) => { foo.doStuff }
case None => {}
}
When what really I wanted was optionFoo.map(_.doStuff) instead. The scala Option cheat sheet is very useful here. http://blog.tmorris.net/scalaoption-cheat-sheet/
Huh? Why is that a bad idea? It makes the code easier to read, and more explicit.
Say, if you’ll add a statement after “return fun(x)”, it’s a definite code smell you’ll notice. However, if you’ll add a statement after `fun(x)`, you might wouldn’t notice, maybe fun(x) has side effects? It would still make sense. So the return saves you a bug here.
@Elazar – it’s a bad idea because it makes refactoring harder. A return can easily (and accidentally) become a non-local return. Good habit is to *never* use return
In idiomatic Scala, explicit use of ‘return’ signals an ‘early return’, that is, it is outside of the normal control flow. This inspection will not highlight early returns. It can also be disabled (alt-enter, right arrow, disable inspection).
I love how the Scala plug-in continues to provide more and more guidance on Scala anti-patterns. It is a huge help in achieving consistent code style and conventions.