Quand écrire une déclaration de retour explicite dans Groovy?

En ce moment, je travaille sur un projet Groovy / Grails (dont je suis assez nouveau) et je me demande si c'est une bonne pratique d'omettre le returnmot - clé dans les méthodes Groovy. Autant que je sache, vous devez insérer explicitement le mot-clé, c'est-à-dire pour les clauses de garde, alors devrait-on l'utiliser également partout ailleurs? À mon avis, le returnmot clé supplémentaire augmente la lisibilité. Ou est-ce quelque chose auquel vous devez simplement vous habituer? Quelle est votre expérience avec ce sujet?

Quelques exemples:

def foo(boolean bar) {
    // Not consistent
    if (bar) {
        return positiveBar()
    }
    negativeBar()
}

def foo2() {
    // Special Grails example
    def entitiy = new Entity(foo: 'Foo', bar: 'Bar')
    entity.save flush: true
    // Looks strange to me this way
    entity
}

J'ajouterais certainement le retour, car cela rend l'intention plus claire à toute personne (y compris vous-même) qui peut venir mettre à jour / maintenir le code plus tard.

Sinon, cela pourrait ressembler à une erreur de frappe.

L'autre chose est de ne pas oublier de déclarer les fonctions / fermetures qui sont censées retourner un vide comme «vide» - encore une fois pour clarifier aux futurs responsables ce que vous essayez de faire.

La clarté est roi.

Faites ce qui est le plus clair pour le programmeur qui doit lire votre code après l'avoir écrit.

Voici un argument pour omettre les instructions de retour ( Source ):

Une fonctionnalité discrète dans Groovy

Contexte

J'ai travaillé avec Groovy pendant un certain temps, mais j'ai été opposé à une caractéristique: le retour implicite de la dernière expression évaluée. Par exemple:

def getFoo() {
  def foo = null
  if (something) {
    foo = new Foo()
  }
  foo // no 'return' necessary
}

Dans le code ci-dessus, j'utiliserais return car cela me semblait plus sûr. J'avais tendance à être d'accord avec la publication d'Eric (en ce qui concerne les retours explicites).

Révélation

Je comprends maintenant, et tout cela grâce aux méthodes de collecte améliorées dans Groovy.

Considérez la méthode de collecte. Il transforme une liste en appliquant une fonction. En pseudocode:

[ a, b, c, d] => [ f(a), f(b), f(c), f(d) ]

Dans cet esprit, voici un autre exemple:

class Composer {
  def name
  // def era, etc
}

def list = [ 'Bach', 'Beethoven', 'Brahms' ]

// the closure returns the new Composer object, as it is the last
// expression evaluated.

def composers = list.collect { item -> new Composer(name : item) }

assert 'Bach' == composers[0].name

L'idée est simplement de construire une liste d'objets Composer à partir d'une liste de chaînes. Comme indiqué dans le commentaire, la fermeture adoptée pour collecter utilise le retour implicite à bon escient. À un moment donné, j'aurais pris 3-4 lignes pour exprimer cette idée.

Mais maintenant, ce code n'est pas simplement concis: il est vraiment élégant. Très proche d'autres langages tels que Python.

Le message à retenir

Il existe de nombreuses listes d'excellentes fonctionnalités Groovy. Cependant, nous voyons rarement «retour implicite» dans la liste. Je suis fan: ça lubrifie les roues pour d'autres fonctionnalités.

Je me rends compte qu'il est disponible dans de nombreuses langues: je ne l'ai tout simplement pas utilisé dans Groovy. Je soupçonne que dans quelques semaines je ne pourrai plus m'en passer.