¿Cuándo escribir una declaración de devolución explícita en Groovy?

21

En este momento estoy trabajando en un proyecto Groovy / Grails (en el que soy bastante nuevo) y me pregunto si es una buena práctica omitir la returnpalabra clave en los métodos Groovy. Hasta donde sé, debe insertar explícitamente la palabra clave, es decir, para las cláusulas de protección, ¿debería uno usarla también en cualquier otro lugar? En mi opinión, la returnpalabra clave adicional aumenta la legibilidad. ¿O es algo a lo que solo tienes que acostumbrarte? ¿Cuál es tu experiencia con ese tema?

Algunos ejemplos:

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
fuente

Hay un problema similar en Perl: una función devuelve la última expresión evaluada en ausencia de una returndeclaración. Personalmente, siempre uso el explícito return, pero no sé Groovy.

— Keith Thompson

2

Personalmente, usaría lo implícito return solo cuando esté perfectamente claro. toStringEs un ejemplo típico: es una línea y el valor calculado es obviamente el valor de retorno. Pero, de nuevo, no he programado suficiente Groovy para saber si eso encaja en lo que piensa la comunidad en general.

— Joachim Sauer

7

Ciertamente agregaría la devolución, ya que aclara la intención de cualquier persona (incluido usted) que pueda venir y actualizar / mantener el código más adelante.

De lo contrario, podría parecer un error de escritura.

La otra cosa es recordar declarar funciones / cierres que se espera que devuelvan un vacío como 'vacío', nuevamente para aclarar a los futuros mantenedores lo que está tratando de hacer.

— adrianmcmenamin
fuente

17

La claridad es el rey.

Haga lo que sea más claro para el programador compañero que tiene que leer su código después de escribirlo.

— Robert Harvey
fuente

8

Aquí hay un argumento para omitir las declaraciones de retorno ( Fuente ):

Una característica entendida en Groovy

Fondo

He trabajado con Groovy por un tiempo, pero he sido reacio a una característica: el retorno implícito de la última expresión evaluada. Por ejemplo:

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

En el código anterior, usaría return porque me pareció más seguro. Solía estar de acuerdo con la publicación de Eric (con respecto a las devoluciones explícitas).

Revelación

Lo entiendo ahora, y todo gracias a los métodos de recolección mejorados en Groovy.

Considere el método de recolección. Transforma una lista aplicando una función. En pseudocódigo:

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

Con eso en mente, aquí hay otro ejemplo:

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

La idea es simplemente construir una lista de objetos Composer a partir de una lista de cadenas. Como se señaló en el comentario, el cierre aprobado para cobrar utiliza el retorno implícito con gran efecto. Hubo un tiempo en que habría tomado 3-4 líneas para expresar esa idea.

Pero ahora, este código no es simplemente conciso: es realmente elegante. Muy parecido a otros lenguajes como Python.

El mensaje para llevar a casa

Hay muchas listas de excelentes características de Groovy. Sin embargo, rara vez vemos "retorno implícito" en la lista. Soy fanático: engrasa las ruedas para otras características.

Me doy cuenta de que está disponible en muchos idiomas: simplemente no lo he usado en Groovy. Sospecho que dentro de unas semanas no podré vivir sin él.

— Chad
fuente