Це гарний стиль явно повернутися в Ruby?

Походячи з фона 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

І будь-якому програмісту було б зрозуміло, що він повертає значення, і набагато важче їм зламати його, не усвідомлюючи цього.

Як варіант, можна написати це так і залишити зворотну заяву ...

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

Але навіщо турбуватися, залишаючи слово повернення? Чому б просто не помістити його туди і зробити 100% зрозумілим, що відбувається? Це буквально не матиме впливу на здатність вашого коду.

Ні. Добрий стиль Ruby, як правило, використовував лише явні повернення для раннього повернення . Рубі - великий мінімалізм коду / неявна магія.

Однак, якщо явне повернення зробить речі зрозумілішими чи легшими для читання, це нічого не зашкодить.

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

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

І останнє, але не менш важливе, я також використовую це розрізнення з блоками: функціональні блоки отримують фігурні дужки, процедурні блоки (тобто блоки, які щось "роблять") do/ end.

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

Насправді важливо розрізняти:

1. Функції - методи, виконані для їх повернення
2. Процедури - методи, виконані для їх побічних ефектів

У Ruby немає власного способу їх розрізнення - це залишає вас вразливим до написання процедури, side_effect()а інший розробник вирішує зловживати неявним поверненням вашої процедури (в основному трактуючи це як нечисту функцію).

Щоб вирішити це, візьміть лист із книги Скали та Хаскелла і переконайтесь, що ваші процедури явно повертаються nil(ака Unitчи ()іншими мовами).

Якщо ви дотримуєтесь цього, то використання явного returnсинтаксису чи не просто стає справою особистого стилю.

Для подальшого розмежування функцій та процедур:

1. Скопіюйте хорошу ідею Йорга У Міттага про написання функціональних блоків фігурними дужками, а процедурні блоки - за допомогою do/end
2. Коли ви викликаєте процедури, використовуйте (), тоді як, коли ви викликаєте функції, не робіть цього

Зауважте, що Йорг W Міттаг насправді виступав навпаки - уникаючи ()процедур s - але це не доцільно, оскільки ви хочете, щоб виклики методу стороннього ефекту були чітко відмінні від змінних, особливо коли значення arity дорівнює 0. Дивіться посібник зі стилю Scala щодо виклику методу для деталі.

Посібник зі стилів зазначає, що ви не повинні використовувати returnв останньому заяві. Ви все одно можете використовувати його, якщо він не останній . Це одна з конвенцій, яких спільнота дотримується суворо, і тому ви повинні, якщо ви плануєте співпрацювати з будь-ким, хто використовує Ruby.

Однак, головний аргумент для використання явного returns полягає в тому, що це заплутано для людей, які походять з інших мов.

• По-перше, це не зовсім виключно Рубі. Наприклад, Perl також має неявну віддачу.
• По-друге, більшість людей, до яких це стосується, походять з алгольських мов. Більшість із них є "нижчим рівнем", ніж Рубі, тому вам доведеться написати більше коду, щоб щось зробити.

Поширена евристика для довжини методу (за винятком геттерів / сеттерів) в java - це один екран . У цьому випадку ви, можливо, не бачите визначення методу та / або вже забули про те, звідки ви поверталися.

З іншого боку, у Ruby найкраще дотримуватися методів довжиною менше 10 рядків . Враховуючи це, варто задатися питанням, чому йому доводиться писати ~ 10% більше заяв, коли вони чітко маються на увазі.

Оскільки у Ruby немає недійсних методів, і все набагато стисліше, ви просто додаєте накладні витрати на жодну з переваг, якщо переходите з явними returns.

Я погоджуюся з Бен Хьюз і не погоджуюся з Тімом Холтом, тому що в питанні згадується про остаточний спосіб, як це робить Питон, і запитує, чи є у Рубі подібний стандарт.

Це робить.

Це настільки відома особливість мови, що кожен, хто очікував налагодження проблеми в рубіні, повинен розумно очікувати про неї.

Це питання, якому стилю ви віддаєте перевагу здебільшого. Вам потрібно використовувати ключове слово return, якщо ви хочете повернутися звідкись із середини методу.

Як сказав Бен. Той факт, що «значення, що повертається методом рубіну, є значенням повернення останнього оператора в тілі функції», призводить до того, що ключове слово повернення рідко використовується в більшості методів рубіну.

def some_func_which_returns_a_list( x, y, z)
  return nil if failed_some_early_check


  # function code 

  @list     # returns the list
end