Когда писать явный оператор возврата в Groovy?

21

В данный момент я работаю над проектом Groovy / Grails (в котором я довольно новичок), и мне интересно, будет ли хорошей практикой опускать returnключевое слово в методах Groovy. Насколько я знаю, вы должны явно вставить ключевое слово, т. Е. Для охранных предложений, поэтому следует ли использовать его также везде? На мой взгляд, дополнительное returnключевое слово повышает читабельность. Или к этому нужно просто привыкнуть? Каков ваш опыт работы с этой темой?

Несколько примеров:

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

— Роланд Шнайдер
источник

В Perl есть похожая проблема: функция возвращает последнее вычисленное выражение в отсутствие returnоператора. Лично я всегда использую явное return, но я не знаю Groovy.

— Кит Томпсон

2

Лично я бы использовал неявное return только тогда, когда это совершенно ясно. toStringТипичный пример: это однострочник, и вычисленное значение, очевидно, является возвращаемым значением. Но опять же, я не запрограммировал достаточно Groovy, чтобы знать, вписывается ли это в то, что думает более широкое сообщество.

— Иоахим Зауэр

7

Я уверен, что добавил бы возвращение, поскольку это делает намерение более ясным любому человеку (включая вас), который может прийти и обновить / поддержать код позже.

В противном случае это может выглядеть как ошибка печати.

Другая вещь - не забывайте объявлять функции / замыкания, которые, как ожидается, будут возвращать void как 'void' - снова, чтобы сделать будущие сопровождающие более понятными, что вы пытаетесь сделать.

— adrianmcmenamin
источник

17

Ясность - король.

Делайте то, что больше всего понятно коллегам-программистам, которые должны читать ваш код после того, как вы его напишите.

— Роберт Харви
источник

8

Вот аргумент для пропуска операторов возврата ( Источник ):

Понятная особенность в Groovy

Фон

Я работал с Groovy некоторое время, но был против одной особенности: неявное возвращение последнего оцененного выражения. Например:

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

В приведенном выше коде я бы использовал return, потому что мне было безопаснее. Я был склонен согласиться с постом Эрика (в отношении явных возвратов).

Открытие

Я понял это сейчас, и все благодаря улучшенным методам сбора в Groovy.

Рассмотрим метод сбора. Преобразует список, применяя функцию. В псевдокоде:

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

Имея это в виду, вот еще один пример:

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

Идея состоит в том, чтобы просто создать список объектов Composer из списка строк. Как отмечено в комментарии, закрытие, переданное для сбора, использует неявный возврат к большому эффекту. В свое время я бы взял 3-4 строки, чтобы выразить эту идею.

Но теперь этот код не просто лаконичен: он действительно элегантен. Очень напоминает другие языки, такие как Python.

Сообщение о возвращении домой

Есть много списков отличных возможностей Groovy. Однако мы редко видим «неявное возвращение» в списке. Я фанат: он смазывает колеса для других функций.

Я понимаю, что это доступно на многих языках: я просто не использовал его в Groovy. Я подозреваю, что через несколько недель я не смогу жить без этого.

— Чад
источник