Wann schreibe ich eine explizite return-Anweisung in Groovy?

21

Im Moment arbeite ich an einem Groovy / Grails-Projekt (in dem ich ziemlich neu bin) und ich frage mich, ob es empfehlenswert ist, das returnSchlüsselwort in Groovy-Methoden wegzulassen . Soweit ich weiß, müssen Sie das Schlüsselwort zB für Guard-Klauseln explizit einfügen, sollte man es also auch überall anders verwenden? Meiner Meinung nach returnerhöht das zusätzliche Schlüsselwort die Lesbarkeit. Oder muss man sich nur daran gewöhnen? Wie ist Ihre Erfahrung mit diesem Thema?

Einige Beispiele:

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
}

coding-style groovy

— Roland Schneider
quelle

In Perl gibt es ein ähnliches Problem: Eine Funktion gibt den zuletzt ausgewerteten Ausdruck zurück, wenn keine returnAnweisung vorhanden ist. Persönlich verwende ich immer das Explizite return, aber ich kenne Groovy nicht.

— Keith Thompson

2

Persönlich würde ich das Implizite return nur verwenden, wenn es vollkommen klar ist. toStringist ein typisches Beispiel: Es ist ein Einzeiler und der berechnete Wert ist offensichtlich der Rückgabewert. Andererseits habe ich nicht genug Groovy programmiert, um zu wissen, ob das in die Meinung der größeren Community passt.

— Joachim Sauer

7

Ich bin mir sicher, dass ich die Rückgabe hinzufügen würde, da dies die Absicht jeder Person (einschließlich Ihrer selbst) klarer macht, die den Code später aktualisieren / pflegen möchte.

Andernfalls könnte es wie ein Tippfehler aussehen.

Die andere Sache ist, sich daran zu erinnern, Funktionen / Abschlüsse, von denen erwartet wird, dass sie eine Lücke zurückgeben, als "Lücke" zu deklarieren.

— adrianmcmenamin
quelle

17

Klarheit ist König.

Tun Sie dem Programmierkollegen, der Ihren Code lesen muss, nachdem Sie ihn geschrieben haben, das, was ihm am klarsten ist.

— Robert Harvey
quelle

8

Hier ist ein Argument für das Weglassen der return-Anweisungen ( Source ):

Eine unterschätzte Eigenschaft in Groovy

Hintergrund

Ich habe eine Weile mit Groovy gearbeitet, war aber einer Eigenschaft abgeneigt: der impliziten Rückkehr des zuletzt ausgewerteten Ausdrucks. Beispielsweise:

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

Im obigen Code würde ich return verwenden, da es sich für mich sicherer anfühlt. Ich stimmte dem Beitrag von Eric eher zu (in Bezug auf explizite Rückgaben).

Offenbarung

Ich verstehe es jetzt und das alles dank der verbesserten Erfassungsmethoden in Groovy.

Betrachten Sie die Erfassungsmethode. Durch Anwenden einer Funktion wird eine Liste transformiert. Im Pseudocode:

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

In diesem Sinne ist hier ein weiteres Beispiel:

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

Die Idee ist einfach, eine Liste von Composer-Objekten aus einer Liste von Zeichenfolgen zu erstellen. Wie in dem Kommentar angemerkt, wird bei dem zum Sammeln übergebenen Abschluss die implizite Rückkehr zu einer großen Wirkung verwendet. Zu einer Zeit hätte ich 3-4 Zeilen genommen, um diese Idee auszudrücken.

Aber jetzt ist dieser Code nicht nur prägnant: Er ist wirklich elegant. Erinnert sehr an andere Sprachen wie Python.

Die Nachricht zum Mitnehmen

Es gibt viele Listen mit hervorragenden Groovy-Funktionen. Wir sehen jedoch selten eine Liste der impliziten Rückgaben. Ich bin ein Fan: Es schmiert die Räder für andere Funktionen.

Mir ist klar, dass es in vielen Sprachen verfügbar ist: Ich habe es in Groovy einfach nicht verwendet. Ich vermute, in ein paar Wochen werde ich nicht mehr ohne leben können.

— Tschad
quelle