tags:

views:

515

answers:

4

With equals sign:

object HelloWorld {
  def main(args: Array[String]) = {
    println("Hello!")
  }
}

Without equals sign:

object HelloWorld {
  def main(args: Array[String]) {
    println("Hello!")
  }
}

Both of the above programs execute the same way. From here I read that when the equals sign is missing, the method will return Unit (same as Java's void), so methods that return a value must use the equals sign. But methods that don't return a value can be written either way.

What is the best practice for using the equals sign in Scala methods that don't return a value?

+5  A: 

Methods which return Unit should always use the non-equals syntax. This avoids potential mistakes in implementation carrying over into the API. For example, you could have accidentally done something like this:

object HelloWorld {
  def main(args: Array[String]) = {
    println("Hello!")
    123
  }
}

Trivial example of course, but you can see how this might be a problem. Because the last expression does not return Unit, the method itself will have a return type other than Unit. This is exposed in the public API, and might cause other problems down the road. With the non-equals syntax, it doesn't matter what the last expression is, Scala fixes the return type as Unit.

It's also two characters cleaner. :-) I also tend to think that the non-equals syntax makes the code just a little easier to read. It is more obvious that the method in question returns Unit rather than some useful value.

On a related note, there is an analogous syntax for abstract methods:

trait Foo {
  def bar(s: String)
}

The method bar has signature String=>Unit. Scala does this when you omit the type annotation on an abstract member. Once again, this is cleaner, and (I think) easier to read.

Daniel Spiewak
Not using the equals sign is also the recommendation in the Scala Style Guide: http://davetron5000.github.com/scala-style/types/inference/void_methods.html
Esko Luontola
I wrote that bit, so you should probably keep that in mind when you weigh the reference. :-)
Daniel Spiewak
+6  A: 

I actually disagree pretty strongly with Daniel. I think the non-equal syntax should never be used. If your method is being exposed as an API and you're worried about accidentally returning the wrong type, add an explicit type annotation:

object HelloWorld {
  def main(args: Array[String]): Unit = {
    println("Hello!")
    123
  }
}

The non-equal syntax is shorter and might look "cleaner", but I think it just adds the possibility of confusion. I have sometimes forgotten to add an equal sign and believed my method was returning a value when actually it was returning Unit. Because the non-equal and equal-with-inferred-type syntaxes are so visually similar, it's easy to miss this problem.

Even though it costs me a little more work, I prefer the explicit type annotations when they matter (namely, exposed interfaces).

Jorge Ortiz
+2  A: 

You must use equals sign in call declarations except the definitions returning Unit.

In this later case, you may forgo the equals sign. This syntax may be deprecated, though, so it's best avoided. Using equals sign and declaring the return type will always work.

Daniel
A: 

One thing : imagine the last statement of a method that should return Unit does not return Unit. Using the non-equal syntax is then very convenient, I hope this will not be deprecated as I see several use case for it

jos