什么时候在 Scala 方法声明中使用等号？

等号:

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

没有等号:

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

上述两个程序执行的方式相同。在博客文章 我不喜欢 Scala 里的东西中，我读到当等号丢失时，该方法将返回 Unit(与 Java 的 void相同) ，因此返回值的方法必须使用等号。但是不返回值的方法可以以任何一种方式编写。

在不返回值的 Scala 方法中使用等号的最佳实践是什么？

12825 次浏览
小开

UPDATE: as of Scala-2.10, using equals sign is preferred. Old answer:

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.

小开
最佳答案

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

小开

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

In this latter 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.

小开

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

小开

As time as progressed the default style has changed, and this has been mentioned in many of the comments to answers, it is recommended in the official style guide to use the = syntax for function declarations.

小开

For methods, Scala Style Guide recommends the equals syntax as opposed to procedure syntax

Procedure Syntax

Avoid the procedure syntax, as it tends to be confusing for very little gain in brevity.

// don't do this
def printBar(bar: Baz) {
println(bar)
}
// write this instead
def printBar(bar: Bar): Unit = {
println(bar)
}
小开

for method that dont have a return value, a way to express such methods is leaving out the result type and the equals sign, following the method with a block enclosed in curly braces. In this form, the method looks like a procedure, a method that is executed only for its side effects.


提交答案