Вопрос

Исходя из опыта Python, где всегда есть «правильный способ сделать это» («Pythonic» способ), когда дело доходит до стиля, мне интересно, существует ли то же самое для Ruby.Я использую свои собственные рекомендации по стилю, но подумываю о том, чтобы опубликовать свой исходный код, и мне бы хотелось, чтобы он соответствовал любым существующим неписаным правилам.

Это «Рубиновый путь» для явного ввода return в методах?Я видел, как это делалось с и без, но есть ли правильный способ сделать это?Может быть, есть право время сделать это?Например:

def some_func(arg1, arg2, etc)
  # Do some stuff...
  return value # <-- Is the 'return' needed here?
end
Это было полезно?

Решение

Старый (и "ответил") вопрос, но в ответ я добавлю два цента.

TL; DR - Вы не обязаны это делать, но в некоторых случаях это может сделать ваш код более понятным.

Хотя не использование явного возврата может быть "способом Ruby", это сбивает с толку программистов, работающих с незнакомым кодом, или незнакомых с этой функцией Ruby.

Это несколько надуманный пример, но в изображении есть небольшая функция, подобная этой, которая добавляет единицу к переданному числу и присваивает ее переменной экземпляра.

def plus_one_to_y(x)
    @y = x + 1
end

Это должна была быть функция, которая возвращала значение, или нет? Сложно сказать, что имел в виду разработчик, поскольку он одновременно назначает переменную экземпляра и возвращает также назначенное значение.

Предположим, намного позже, другой программист (возможно, не очень хорошо знакомый с тем, как Ruby возвращает результаты, основанные на последней строке выполненного кода), хочет добавить некоторые операторы печати для регистрации, и функция становится такой ...

def plus_one_to_y(x)
    @y = x + 1
    puts "In plus_one_to_y"
end

Теперь функция не работает , если что-либо ожидает возвращаемого значения . Если ничто не ожидает возвращаемого значения, это нормально. Ясно, что если где-то дальше по цепочке кода, что-то, вызывающее это, ожидает возвращаемое значение, оно потерпит неудачу, поскольку не вернет то, что ожидает.

Реальный вопрос сейчас заключается в следующем: ожидало ли что-нибудь возвращаемое значение? Это что-то сломало или нет? Это что-то сломает в будущем? Кто знает! Только полный просмотр кода всех звонков даст вам знать.

Так что, по крайней мере, для меня наилучший практический подход - либо четко указывать, что вы возвращаете что-то, если это имеет значение, либо вообще ничего не возвращать, если это не так.

Так что в случае нашей маленькой демонстрационной функции, если мы хотим, чтобы она возвращала значение, она была бы написана так ...

def plus_one_to_y(x)
    @y = x + 1
    puts "In plus_one_to_y"
    return @y
end

И любому программисту было бы совершенно ясно, что оно возвращает значение, и им гораздо труднее его сломать, не осознавая этого.

С другой стороны, можно написать это так и пропустить оператор return ...

def plus_one_to_y(x)
    @y = x + 1
    puts "In plus_one_to_y"
    @y
end

Но зачем вообще не возвращать слово? Почему бы просто не положить это туда и не дать на 100% понять, что происходит? Это буквально не повлияет на способность вашего кода выполнять.

Другие советы

Нет.Хороший стиль Ruby обычно использует только явные возвраты для раннее возвращение.Ruby хорош в минимализме кода и неявной магии.

Тем не менее, если явный возврат прояснит ситуацию или упростит чтение, это ничему не повредит.

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

Я использую то же различие при вызове методов: функциональные методы получают круглые скобки, а процедурные - нет.

И последнее, но не менее важное: я также использую это различие с блоками: функциональные блоки получают фигурные скобки, процедурные блоки (то есть блоки, которые «что-то делают») получают do / end .

Однако я стараюсь не быть религиозным по этому поводу: с блоками, фигурными скобками и do / end имеют другой приоритет, а не добавление явных скобок для устранения неоднозначности выражение, я просто переключаюсь на другой стиль. То же самое относится и к вызову метода: если добавление скобок вокруг списка параметров делает код более читабельным, я делаю это, даже если рассматриваемый метод носит процедурный характер.

На самом деле важно различать:

<Ол>
  • Функции - методы, выполняемые для возвращаемого значения
  • Процедуры - методы, выполняемые для их побочных эффектов
  • В Ruby нет собственного способа их различения, что делает вас уязвимым для написания процедуры side_effect () , а другой разработчик решает злоупотребить неявным возвращаемым значением вашей процедуры (в основном рассматривая его как нечистая функция).

    Чтобы решить эту проблему, возьмите лист из книги Scala и Haskell и попросите ваши процедуры явно вернуть nil (иначе Unit или () на других языках).

    Если вы следуете этому, то использование явного синтаксиса return или не только становится делом личного стиля.

    Для дальнейшего различения функций и процедур:

    <Ол>
  • Скопируйте J & # 246; rg W Хорошая идея Миттага о написании функциональных блоков с фигурными скобками и процедурных блоков с помощью do / end
  • Когда вы вызываете процедуры, используйте () , тогда как когда вы вызываете функции, не
  • Обратите внимание, что J & M. W Mittag на самом деле выступал с другой стороны - избегая () для процедур - но это не рекомендуется, потому что вы хотите, чтобы вызовы побочных эффектов были четко отличимы от переменных особенно когда arity равен 0. См. руководство по стилю Scala для вызова метода для деталей.

    Руководство по стилю утверждает, что вам не следует использовать return по вашему последнему заявлению.Вы все еще можете использовать его если это не последний.Это одно из соглашений, которому сообщество строго следует, и вам тоже следует следовать этому соглашению, если вы планируете сотрудничать с кем-либо, использующим Ruby.


    При этом основной аргумент в пользу использования явного returnДело в том, что это сбивает с толку людей, говорящих на других языках.

    • Во-первых, это не только особенность Ruby.Например, в Perl тоже есть неявные возвраты.
    • Во-вторых, большинство людей, к которым это относится, происходят из языков Алголя.Большинство из них - путь "Нижний уровень" чем Ruby, поэтому вам придется писать больше кода, чтобы что-то сделать.

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

    С другой стороны, в Ruby лучше всего придерживаться методов длина менее 10 строк.Учитывая это, можно было бы задаться вопросом, почему ему приходится писать примерно на 10% больше утверждений, если они явно подразумеваются.


    Поскольку у Руби нет пустота методы и все гораздо более лаконично, вы просто добавляете накладные расходы, не получая никаких преимуществ, если вы используете явное returnс.

    Я согласен с Беном Хьюзом и не согласен с Тимом Холтом, потому что в этом вопросе упоминается окончательный способ, которым Python делает это, и спрашивает, есть ли у Ruby аналогичный стандарт.

    Это так.

    Это настолько известная особенность языка, что любой, кто ожидал отладить проблему в ruby, должен был знать о ней.

    Вопрос в том, какой стиль вы предпочитаете по большей части. Вы должны использовать ключевое слово return, если хотите вернуться откуда-то посередине метода.

    Как сказал Бен.Тот факт, что «возвращаемое значение метода Ruby является возвращаемым значением последнего оператора в теле функции», приводит к тому, что ключевое слово return редко используется в большинстве методов Ruby.

    def some_func_which_returns_a_list( x, y, z)
      return nil if failed_some_early_check
    
    
      # function code 
    
      @list     # returns the list
    end
    
    Лицензировано под: CC-BY-SA с атрибуция
    Не связан с StackOverflow
    scroll top