CODEWITHSUNDEEP
scalacoding-stylereturn
Rafe Kettler
Rafe Kettler

Reputation: 76945

Should I use returns in multiline Scala methods?

Perhaps this is just my background in more imperative programming, but I like having return statements in my code.

I understand that in Scala, returns are not necessary in many methods, because whatever the last computed value is is returned by default. I understand that this makes perfect sense for a "one-liner", e.g.

def square(x) = x * x

I also understand the definitive case for using explicit returns (when you have several branches your code could take, and you want to break out of the method for different branches, e.g. if an error occurs). But what about multiline functions? Wouldn't it be more readable and make more sense if there was an explicit return, e.g.

def average(x: List[Int]) : Float = {
  var sum = 0
  x.foreach(sum += _)
  return sum / x.length.toFloat
}

Upvotes: 4

Views: 2400

Answers (5)

Aaron Novstrup
Aaron Novstrup

Reputation: 21017

Your sense that the version with the return is more readable is probably a sign that you are still thinking imperatively rather than declaratively. Try to think of your function from the perspective of what it is (i.e. how it is defined), rather than what it does (i.e. how it is computed).

Let's look at your average example, and pretend that the standard library doesn't have the features that make an elegant one-liner possible. Now in English, we would say that the average of a list of numbers is the sum of the numbers in the list divided by its length.

def average(xs: List[Int]): Float = {
   var sum = 0
   xs.foreach(sum += _)
   sum / xs.length.toFloat
}

This description is fairly close to the English version, ignoring the first two lines of the function. We can factor out the sum function to get a more declarative description:

def average(xs: List[Int]): Float = {
   def sum(xs: List[Int]): Int = // ...
   sum(xs) / xs.length.toFloat
}

In the declarative definition, a return statement reads quite unnaturally because it explicitly puts the focus on doing something.

Upvotes: 3

hbatista
hbatista

Reputation: 1237

I believe you should not use return, I think it somehow goes against the elegant concept that in Scala everything is an expression that evaluates to something.

Like your average method: it's just an expression that evaluates to Float, no need to return anything to make that work.

Upvotes: 0

IttayD
IttayD

Reputation: 29113

def average(x: List[Int]) : Float = 
  x.foldLeft(0)(_ + _) / x.length.toFloat

UPDATE: While I was aiming to show how an iterative code can be made into a functional expression, @soc rightly commented that an even shorter version is x.sum / x.length.toFloat

I usually find that in Scala I have less need to "return in the middle". Furthermore, a large function is broken into smaller expressions that are clearer to reason. So instead of

var x = ...
if (some condition) x = ...
else x = ...

I would write if (some condition) ... else ....

Similar thing happens using match expressions. And you can always have helper nested classes.

Once you are comfortable with many forms of expressions that evaluate to a result (e.g., 'if') without a return statement, then having one in your methods looks out of place.

At one place of work we had a rule of not having 'return' in the middle of a method since it is easy for a reader of your code to miss it. If 'return' is only at the last line, what's the point of having it at all?

Upvotes: 11

kiritsuku
kiritsuku

Reputation: 53348

I don't miss the return-statement at the end of a method because it is unnecessary. Furthermore, in Scala each method does return a value - even methods which should not return something. Instead of void there is the type Unit which is returned:

def x { println("hello") }

can be written as:

def x { println("hello"); return Unit }

But println returns already the type Unit - thus when you explicitly want to use a return-statement you have to use it in methods which return Unit, too. Otherwise you do not have continuous identical build-on code.

But in Scala there is the possibility to break your code in a lot of small methods:

def x(...): ReturnType = {
  def func1 = ... // use funcX
  def func2 = ... // use funcX
  def func3 = ... // use funcX
  funcX
}

An explicitly used return-statement does not help to understand the code better.

Also Scala has a powerful core library which allows you to solve many problems with less code:

def average(x: List[Int]): Float = x.sum.toFloat / x.length

Upvotes: 2

Rex Kerr
Rex Kerr

Reputation: 167871

The return doesn't tell you anything extra, so I find it actually clutters my understanding of what goes on. Of course it returns; there are no other statements!

And it's also a good idea to get away from the habit of using return because it's really unclear where you are returning to when you're using heavily functional code:

def manyFutures = xs.map(x => Futures.future { if (x<5) return Nil else x :: Nil })

Where should the return leave execution? Outside of manyFutures? Just the inner block?

So although you can use explicit returns (at least if you annotate the return type explicitly), I suggest that you try to get used to the last-statement-is-the-return-value custom instead.

Upvotes: 10

Related Questions