84 votes

Quand utiliser le signe égal dans une déclaration de méthode Scala ?

Avec le signe égal :

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

Sans signe égal :

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

Les deux programmes ci-dessus s'exécutent de la même manière. Dans le billet de blog _Ce que je n'aime pas dans Scala_ J'ai lu que lorsque le signe égal est manquant, la méthode renverra Unit (identique à la fonction void ), les méthodes qui renvoient une valeur doivent donc utiliser le signe égal. En revanche, les méthodes qui ne renvoient pas de valeur peuvent être écrites de l'une ou l'autre manière.

Quelle est la meilleure pratique pour utiliser le signe égal dans les méthodes Scala qui ne renvoient pas de valeur ?

105voto

Jorge Ortiz Points 3374

En fait, je ne suis pas du tout d'accord avec Daniel. Je pense que la syntaxe de non-égalité devrait jamais être utilisé. Si votre méthode est exposée en tant qu'API et que vous craignez de renvoyer accidentellement le mauvais type, ajoutez une annotation de type explicite :

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

La syntaxe non égale est plus courte et peut sembler plus "propre", mais je pense qu'elle ne fait qu'ajouter un risque de confusion. Il m'est arrivé d'oublier d'ajouter un signe égal et de croire que ma méthode renvoyait une valeur alors qu'en réalité elle renvoyait Unit. Étant donné que les syntaxes non égal et égal avec type inféré sont visuellement très similaires, il est facile de ne pas s'apercevoir de ce problème.

Même si cela me coûte un peu plus de travail, je préfère les annotations de type explicites lorsqu'elles sont importantes (à savoir, les interfaces exposées).

41voto

Daniel Spiewak Points 30706

MISE À JOUR : à partir de Scala-2.10, il est préférable d'utiliser le signe égal. Ancienne réponse :

Les méthodes qui renvoient Unit devrait toujours utiliser la syntaxe de la non-équivalence. Cela permet d'éviter que des erreurs potentielles de mise en œuvre ne se répercutent sur l'API. Par exemple, vous auriez pu accidentellement faire quelque chose comme ceci :

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

Il s'agit bien sûr d'un exemple trivial, mais vous pouvez voir comment cela peut poser un problème. Parce que la dernière expression fait pas retour Unit la méthode elle-même aura un type de retour autre que Unit . Ceci est exposé dans l'API publique, et pourrait causer d'autres problèmes à l'avenir. Avec la syntaxe "non-equals", peu importe la dernière expression, Scala fixe le type de retour à Unit .

C'est aussi un nettoyeur à deux caractères :-) J'ai également tendance à penser que la syntaxe non égale rend le code un peu plus facile à lire. Il est plus évident que la méthode en question renvoie Unit plutôt qu'une valeur utile.

Dans le même ordre d'idées, il existe une syntaxe analogue pour les méthodes abstraites :

trait Foo {
  def bar(s: String)
}

La méthode bar possède une signature String=>Unit . Scala le fait lorsque vous omettez l'annotation de type sur un membre abstrait. Encore une fois, c'est plus propre et (je pense) plus facile à lire.

12voto

Daniel C. Sobral Points 159554

Vous doit utiliser le signe égal dans les déclarations d'appel, à l'exception des définitions renvoyant à Unit.

Dans ce dernier cas, vous peut renoncer au signe égal. Cette syntaxe peut être dépréciée, il est donc préférable de l'éviter. L'utilisation du signe égal et la déclaration du type de retour fonctionneront toujours.

0voto

jos Points 9

Une chose : imaginez que la dernière instruction d'une méthode qui devrait renvoyer Unit ne renvoie pas Unit. L'utilisation de la syntaxe non-égale est alors très pratique, j'espère qu'elle ne sera pas dépréciée car je vois plusieurs cas d'utilisation.

0voto

BeepDog Points 1891

Au fil du temps, le style par défaut a changé, ce qui a été mentionné dans de nombreux commentaires aux réponses. guide de style officiel pour utiliser le = pour les déclarations de fonctions.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X