Звідки взялося поняття "єдиного повернення"?

Я часто розмовляю з програмістами, які говорять " Не кладіть кілька заяв на повернення одним і тим же методом ". Коли я прошу їх сказати мені причини, чому я отримую лише " Стандарт кодування так говорить " або " Це заплутано ". Коли вони показують мені рішення з одним твердженням повернення, код мені виглядає більш неприємним. Наприклад:

if (condition)
   return 42;
else
   return 97;

" Це некрасиво, ви повинні використовувати локальну змінну! "

int result;
if (condition)
   result = 42;
else
   result = 97;
return result;

Як це 50-відсоткове розширення коду полегшує розуміння програми? Особисто мені це важче, тому що простір станів просто збільшився ще однією змінною, яку легко можна було б запобігти.

Звичайно, зазвичай я просто напишу:

return (condition) ? 42 : 97;

Але багато програмістів уникають умовного оператора і віддають перевагу довгій формі.

Звідки взялося це поняття "єдиного повернення"? Чи є історична причина, чому ця конвенція виникла?

"Один запис, одинарний вихід" було написано, коли більшість програмувань проводилися мовою асемблери, FORTRAN або COBOL. Це було широко витлумачено неправильно, оскільки сучасні мови не підтримують практики, проти яких Діккстра застеріг.

"Один запис" означав "не створювати альтернативних точок входу для функцій". Зворотною мовою, звичайно, можна ввести функцію в будь-якій інструкції. FORTRAN підтримував декілька записів до функцій з ENTRYоператором:

      SUBROUTINE S(X, Y)
      R = SQRT(X*X + Y*Y)
C ALTERNATE ENTRY USED WHEN R IS ALREADY KNOWN
      ENTRY S2(R)
      ...
      RETURN
      END

C USAGE
      CALL S(3,4)
C ALTERNATE USAGE
      CALL S2(5)

"Одноразовий вихід" означав, що функція повинна повертатися лише в одне місце: оператор безпосередньо після виклику. Це не означало, що функція повинна повертатися лише з одного місця. Коли було написано Структуроване програмування , звичайною практикою для функції є вказівка ​​на помилку, повернення до іншого місця. FORTRAN підтримав це за допомогою "альтернативного повернення":

C SUBROUTINE WITH ALTERNATE RETURN.  THE '*' IS A PLACE HOLDER FOR THE ERROR RETURN
      SUBROUTINE QSOLVE(A, B, C, X1, X2, *)
      DISCR = B*B - 4*A*C
C NO SOLUTIONS, RETURN TO ERROR HANDLING LOCATION
      IF DISCR .LT. 0 RETURN 1
      SD = SQRT(DISCR)
      DENOM = 2*A
      X1 = (-B + SD) / DENOM
      X2 = (-B - SD) / DENOM
      RETURN
      END

C USE OF ALTERNATE RETURN
      CALL QSOLVE(1, 0, 1, X1, X2, *99)
C SOLUTION FOUND
      ...
C QSOLVE RETURNS HERE IF NO SOLUTIONS
99    PRINT 'NO SOLUTIONS'

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

Це поняття Single Entry, Single Exit (SESE) походить з мов із чітким керуванням ресурсами , як, наприклад, C та зборка. У З таким кодом буде витікати ресурси:

void f()
{
  resource res = acquire_resource();  // think malloc()
  if( f1(res) )
    return; // leaks res
  f2(res);
  release_resource(res);  // think free()
}

У таких мовах у вас є три варіанти:

• Повторіть код очищення.
  Тьфу. Надлишок завжди поганий.

• Використовуйте a, gotoщоб перейти до коду очищення.
  Для цього потрібен код очищення як останнє в функції. (І тому деякі стверджують, що gotoмає своє місце. І це справді - в C.)

• Введіть локальну змінну та маніпулюйте потоком управління через це.
  Недоліком є те, що управління потоком маніпулюють з допомогою синтаксису (думаю break, return, if, while) набагато легше стежити , ніж потік управління маніпулюють через стан змінних (оскільки ці змінні не мають стану , коли ви дивитеся на алгоритмі).

У монтажі це ще більш дивно, тому що ви можете переходити на будь-яку адресу функції, коли ви викликаєте цю функцію, що фактично означає, що у вас є майже необмежена кількість вхідних точок до будь-якої функції. (Іноді це корисно. Такі гроти - це поширена техніка для компіляторів для здійснення thisкоригування вказівника, необхідного для виклику virtualфункцій у сценаріях множинного успадкування в C ++.)

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

Однак, коли в мові є винятки, (майже) будь-яка функція може бути запущена передчасно (майже) в будь-якій точці, тому потрібно все-таки передбачити умови для передчасного повернення. (Я думаю finally, що використовується в основному для цього в Java та using(при впровадженні IDisposable, finallyінакше) в C #; C ++ замість цього використовується RAII .) Після цього ви не зможете не прибрати очищення після себе через раннє returnтвердження, так що, ймовірно, найсильніший аргумент на користь SESE зник.

Це залишає читабельність. Звичайно, функція 200 LoC з півдюжиною returnвисловлювань, випадковим чином розсипається над нею, не є гарним стилем програмування і не робить для читабельного коду. Але таку функцію було б легко зрозуміти і без цих передчасних повернень.

У мовах, де ресурсами не слід керувати або не слід керувати ними вручну, мало дотримується старої конвенції SESE або її немає. Як я вже заперечував, OTOH, часто SESE робить код складнішим . Це динозавр, який (за винятком С) не добре вписується в більшість сучасних мов. Замість того, щоб допомагати зрозумілості коду, він перешкоджає цьому.

Чому програмісти Java дотримуються цього? Я не знаю, але від моєї (ззовні) POV, Java взяла багато конвенцій від C (де вони мають сенс) і застосувала їх до свого OO світу (де вони марні чи відверто погані), де зараз це дотримується їх, незалежно від витрат. (Як і угода про визначення всіх змінних на початку області.)

Програмісти дотримуються всіляких дивних позначень з нераціональних причин. (Глибоко вкладені структурні висловлювання - «наконечники стріл» - колись розглядалися як прекрасний код на мовах, таких як Паскаль.) Застосування чистого логічного міркування до цього, здається, не може переконати більшість із них відхилитися від встановлених ними способів. Найкращий спосіб змінити такі звички - це, мабуть, навчити їх рано робити те, що найкраще, а не те, що є звичайним. Ви, будучи викладачем програмування, маєте це в руці.:)

З одного боку, окремі заяви повернення полегшують ведення журналу, а також форми налагодження, які залежать від ведення журналу. Я пам’ятаю багато разів, коли мені доводилося зводити функцію до єдиного повернення лише для того, щоб надрукувати значення повернення в одну точку.

  int function() {
     if (bidi) { print("return 1"); return 1; }
     for (int i = 0; i < n; i++) {
       if (vidi) { print("return 2"); return 2;}
     }
     print("return 3");
     return 3;
  }

З іншого боку, ви можете переробити це на function()те, що викликає _function()і записує результат.

"Єдиний вхід, єдиний вихід" виник із революцією Структурного програмування початку 1970-х років, яку розпочав лист Едсгера У. Дійкстри до редактора " Заява GOTO вважається шкідливою ". Концепції структурованого програмування були детально викладені в класичній книзі "Структуроване програмування" Оле Йохана-Даля, Едсгера У. Дійкстри та Чарльза Ентоні Річарда Хоара.

"GOTO-заява вважається шкідливою" потрібно прочитати навіть сьогодні. "Структуроване програмування" датоване, але все ще дуже, дуже корисно, і воно повинно бути вгорі у списку "Потрібно читати" будь-якого розробника, набагато вище, ніж, наприклад, Стів МакКоннелл. (У розділі Даля викладені основи занять у Simula 67, які є технічною основою для класів на C ++ та всього об’єктно-орієнтованого програмування.)

Пов’язати Фоулера завжди просто.

Одним з головних прикладів, які ідуть проти SESE, є положення про охорону:

Замініть вкладені умовні положення охоронними

Використовуйте положення про охорону у всіх особливих випадках

double getPayAmount() {
    double result;
    if (_isDead) result = deadAmount();
    else {
        if (_isSeparated) result = separatedAmount();
        else {
            if (_isRetired) result = retiredAmount();
            else result = normalPayAmount();
        };
    }
return result;
};  

                                                                                                        

double getPayAmount() {
    if (_isDead) return deadAmount();
    if (_isSeparated) return separatedAmount();
    if (_isRetired) return retiredAmount();
    return normalPayAmount();
};  

Для отримання додаткової інформації див. Сторінку 250 із Refactoring ...

Я написав повідомлення в блозі на цю тему.

Суть полягає в тому, що це правило походить від віку мов, які не мають сміття чи обробку винятків. Не існує офіційного дослідження, яке б показало, що це правило призводить до кращого кодування в сучасних мовах. Не соромтесь ігнорувати це, коли це призведе до скорочення або більш читаного коду. Хлопці Java, які наполягають на цьому, сліпо і сумнівно дотримуються застарілого, безглуздого правила.

Це питання також було задано на Stackoverflow

Одне повернення полегшує рефакторинг. Спробуйте виконати "метод вилучення" до внутрішнього корпусу циклу for, який містить повернення, розрив або продовження. Це не вдасться, оскільки ви порушили контрольний потік.

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

Часто я стикаюся з проблемою, що мені доводиться повністю переформулювати функції, якщо вони містять контрольні вимикачі потоку і якщо я хочу додати лише невелику функціональність. Це дуже схильне до помилок, коли ви змінюєте весь потік управління замість того, щоб вводити нові шляхи до ізольованих гнізд. Якщо у вас є лише одне повернення в кінці або якщо ви використовуєте охоронців для виходу з циклу, ви, звичайно, маєте більше гніздування та більше коду. Але ви отримуєте можливості компілятора та IDE, що підтримують рефакторинг.

Розглянемо той факт, що кілька операторів повернення еквівалентно наявності GOTO в одній заяві повернення. Це той самий випадок із заявами про перерви. Таким чином, деякі, як я, вважають їх GOTO для всіх намірів та цілей.

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

Моє загальне правило: GOTO призначені лише для контролю потоку. Вони ніколи не повинні використовуватися для циклічного циклу, і ви ніколи не повинні GOTO "вгору" або "назад". (як працює перерва / повернення)

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

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

Цикломатична складність

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

Зміна типу повернення

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

Багаторазовий вихід

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

Реконструйований розчин

Рішення декількох операторів повернення полягає в тому, щоб замінити їх поліморфізмом мають єдине повернення після вирішення необхідного об'єкта реалізації.