Redundant Return

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.

This entry was posted in Uncategorized. Bookmark the permalink.

5 Responses to Redundant Return

  1. Will Sargent says:

    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 instead. The scala Option cheat sheet is very useful here.

  2. Elazar Leibovich says:

    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.

    • oxbow_lakes says:

      @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

  3. Jason Zaugg says:

    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).

  4. Alain O'Dea says:

    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.

Leave a Reply

Your email address will not be published. Required fields are marked *