Інвертуйте оператор "якщо", щоб зменшити розміщення

Наприклад, коли я запустив ReSharper на свій код, наприклад:

    if (some condition)
    {
        Some code...            
    }

ReSharper видав мені вищезазначене попередження (Інвертувати заявку "якщо" для зменшення введення) та запропонував таке виправлення:

   if (!some condition) return;
   Some code...

Я хотів би зрозуміти, чому це краще. Я завжди вважав, що використовувати "повернення" в середині методу проблематично, дещо як "goto".

Повернення в середині методу не обов’язково погано. Можливо, буде краще повернутися негайно, якщо це зробить наміри коду яснішими. Наприклад:

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

У цьому випадку, якщо _isDeadце правда, ми можемо негайно вийти з методу. Можливо, краще структурувати це таким чином:

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

    return normalPayAmount();
};   

Я вибрав цей код із каталогу рефакторингу . Цей специфічний рефакторинг називається: Замініть вкладене умовне на захисні пропозиції.

Це не тільки естетично , але й знижує максимальний рівень гніздування всередині методу. Це, як правило, розцінюється як плюс, оскільки це полегшує розуміння методів (і справді, багато інструментів статичного аналізу дають змогу визначити це як один із показників якості коду).

З іншого боку, ваш метод також має декілька точок виходу, те, що інша група людей вважає, що це немає.

Особисто я погоджуюся з ReSharper та першою групою (мовою, яка має винятки, мені здається дурним обговорювати "кілька точок виходу"; майже все можна кинути, тому у всіх методах є численні потенційні точки виходу).

Щодо продуктивності : обидві версії повинні бути еквівалентними (якщо не на рівні IL, то, безумовно, після закінчення тремтіння з кодом) на всіх мовах. Теоретично це залежить від компілятора, але практично будь-який широко використовуваний сьогодні компілятор здатний обробляти набагато більш досконалі випадки оптимізації коду, ніж цей.

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

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

Передумови - чудовий приклад того, коли нормально повернутися рано на початку функції. Чому на читабельність решти функції має впливати наявність перевірки передумов?

Щодо негативів щодо повернення декількох разів з методу - налагоджувачі зараз досить потужні, і дізнатися, де і коли повертається певна функція, дуже просто.

Наявність декількох повернень у функції не вплине на роботу програміста з технічного обслуговування.

Погана читабельність коду буде.

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

public void myfunction(double exampleParam){
    if(exampleParam > 0){
        //Body will *not* be executed if Double.IsNan(exampleParam)
    }
}

Порівнюйте це з наче рівнозначною інверсією:

public void myfunction(double exampleParam){
    if(exampleParam <= 0)
        return;
    //Body *will* be executed if Double.IsNan(exampleParam)
}

Тож за певних обставин те, що видається правильно перевернутим, ifможе бути і не.

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

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

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

Я хотів би додати, що є ім'я для тих, хто перевернуто, якщо є - Застереження. Я використовую його, коли можу.

Я ненавиджу код для читання там, де на початку два екрани коду та більше нікого. Просто оберніть, якщо і повернутися. Таким чином ніхто не витрачатиме час на прокрутку.

http://c2.com/cgi/wiki?GuardClause

Це не тільки впливає на естетику, але й запобігає введенню коду.

Насправді він може функціонувати як передумова для того, щоб ваші дані також були дійсними.

Це, звичайно, суб'єктивно, але я думаю, що це сильно покращується у двох аспектах:

• Зараз відразу очевидно, що вашій функції нічого не залишається робити, якщо вона conditionвиконується.
• Це дозволяє знизити рівень гніздування. Вкладення шкодить читабельності більше, ніж ви думаєте.

Кілька точок повернення були проблемою в C (і меншою мірою C ++), оскільки вони змусили вас дублювати код очищення перед кожною з точок повернення. Зі збиранням сміття, try| finallyконструювати та usingблокувати, насправді немає причин, чому ви повинні їх боятися.

Зрештою, це зводиться до того, що вам та вашим колегам легше читати.

В залежності від продуктивності, між двома підходами помітної різниці не буде.

Але кодування - це більше, ніж продуктивність. Чіткість та ремонтопридатність також дуже важливі. І у таких випадках, коли це не впливає на продуктивність, це єдине, що має значення.

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

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

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

Застереження або попередні умови (як ви, мабуть, бачите) перевірте, чи виконується певна умова, а потім порушує потік програми. Вони чудово підходять для місць, де вас насправді цікавить лише один результат ifзаяви. Тому замість того, щоб сказати:

if (something) {
    // a lot of indented code
}

Ви скасовуєте умову та перериваєтесь, якщо ця обернена умова виконується

if (!something) return false; // or another value to show your other code the function did not execute

// all the code from before, save a lot of tabs

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

Ви побачите найкращі приклади того, як це можна застосувати в вкладених умовах:

if (something) {
    do-something();
    if (something-else) {
        do-another-thing();
    } else {
        do-something-else();
    }
}

vs:

if (!something) return;
do-something();

if (!something-else) return do-something-else();
do-another-thing();

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

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

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

Продуктивність складається з двох частин. У вас є продуктивність, коли програмне забезпечення виробляється, але ви також хочете мати продуктивність під час розробки та налагодження. Останнє, що хоче розробник, - це «чекати» чогось тривіального. Зрештою, компіляція цього з увімкненою оптимізацією призведе до подібного коду. Тож добре знати ці маленькі хитрощі, які окупаються в обох сценаріях.

Справа у питанні зрозуміла, ReSharper правильний. Замість того, щоб вкладати ifзаяви і створювати нову область в коді, ви встановлюєте чітке правило на початку свого методу. Це збільшує читабельність, легше буде дотримуватися, і це зменшує кількість правил, які вам доведеться просіяти, щоб знайти, куди вони хочуть піти.

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

напр.

 bool PerformDefaultOperation()
 {
      bool succeeded = false;

      DataStructure defaultParameters;
      if ((defaultParameters = this.GetApplicationDefaults()) != null)
      {
           succeeded = this.DoSomething(defaultParameters);
      }

      return succeeded;
 }

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

Багато вагомих причин того, як виглядає код . А як щодо результатів ?

Давайте подивимось на якийсь код C # та його скомпільовану форму IL:

using System;

public class Test {
    public static void Main(string[] args) {
        if (args.Length == 0) return;
        if ((args.Length+2)/3 == 5) return;
        Console.WriteLine("hey!!!");
    }
}

Цей простий фрагмент можна скласти. Ви можете відкрити згенерований .exe файл за допомогою ildasm і перевірити, який результат. Я не буду публікувати всю роботу з асемблером, але опишу результати.

Створений код IL виконує наступні дії:

1. Якщо перша умова помилкова, переходить до коду, де є друга.
2. Якщо це правда, переходить до останньої інструкції. (Примітка: остання інструкція - це повернення).
3. У другій умові те саме відбувається після підрахунку результату. Порівняйте та: потрапили до Console.WriteLine, якщо помилкові, або до кінця, якщо це правда.
4. Роздрукуйте повідомлення та поверніться.

Тож здається, що код підскочить до кінця. Що робити, якщо ми робимо нормальний, якщо з вкладеним кодом?

using System;

public class Test {
    public static void Main(string[] args) {
        if (args.Length != 0 && (args.Length+2)/3 != 5) 
        {
            Console.WriteLine("hey!!!");
        }
    }
}

Результати досить схожі в інструкціях щодо ІЛ. Різниця полягає в тому, що раніше були стрибки за умовою: якщо помилка переходить до наступного фрагмента коду, якщо правда - перейти до кінця. І тепер код IL протікає краще і має 3 стрибки (компілятор трохи оптимізував це): 1. Перший стрибок: коли довжина дорівнює 0 до частини, де код знову стрибає (Третій стрибок) до кінця. 2. Другий: посеред другої умови уникати однієї інструкції. 3. Третє: якщо друга умова помилкова, перескочіть до кінця.

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

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

Більше про галузеве прогнозування тут .

Це просто суперечливо. Немає «згоди між програмістами» щодо питання якнайшвидшого повернення. Наскільки я знаю, це завжди суб'єктивно.

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

Я не думаю, що ви отримаєте остаточну відповідь на це питання.

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

Я вважав свій код дійсно нечитабельним, коли писав хост-програму ASIO за допомогою ASIOSDK Steinberg, коли дотримувався парадигми введення. Це пішло як вісім рівнів глибоко, і я не можу побачити вади дизайну там, про що згадував Ендрю Буллок вище. Звичайно, я міг би запакувати якийсь внутрішній код до іншої функції, а потім вклав там інші рівні, щоб зробити його більш читабельним, але це здається мені досить випадковим.

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

Тож це може бути інша ситуація, коли перевернуті ifs можуть сприяти більш чіткому коду.

Уникнення кількох точок виходу може призвести до підвищення продуктивності. Я не впевнений, що стосується C #, але в C ++ оптимізація іменованого зворотного значення (Copy Elision, ISO C ++ '03 12.8 / 15) залежить від наявності однієї точки виходу. Ця оптимізація дозволяє уникнути побудови копії для повернення значення (у вашому конкретному прикладі це не має значення). Це може призвести до значного збільшення продуктивності в тісних петлях, оскільки ви зберігаєте конструктор і деструктор щоразу, коли функція викликається.

Але в 99% випадків збереження додаткових викликів конструктора та деструктора не варто ifвводити втрату читабельності вкладених блоків (як вказували інші).

Це питання думки.

Моїм нормальним підходом було б уникати однорядних ifs, а повертається в середині методу.

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

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

Якщо ви насправді повертаєте returnValue - вкладення, як правило, є кращим способом, тому що ви повертаєте returnValue просто в одному місці (в кінці - duh), і це може зробити ваш код більш рентабельним у цілій безлічі випадків.

Я не впевнений, але думаю, що R # намагається уникати далеких стрибків. Коли у вас IF-ELSE, компілятор робить щось подібне:

Умова false -> далеко перейти до false_condition_label

true_condition_label: інструкція1 ... інструкція_n

false_condition_label: інструкція1 ... інструкція_n

кінцевий блок

Якщо умова справжня, немає стрибка та кешу L1 розгортання, але перехід до false_condition_label може бути дуже далеко, і процесор повинен розгорнути власний кеш. Синхронізувати кеш - це дорого. R # намагається замінити далекі стрибки на короткі стрибки, і в цьому випадку більша ймовірність того, що всі інструкції вже є в кеші.

Я думаю, це залежить від того, що ви віддаєте перевагу, як зазначалося, немає загальної згоди afaik. Щоб зменшити роздратування, ви можете зменшити подібне попередження до "Підказки"

Моя ідея полягає в тому, що повернення "посеред функції" не повинно бути таким "суб'єктивним". Причина досить проста: візьміть цей код:

    функція do_something (дані) {

      if (! is_valid_data (дані)) 
            повернути помилкове;


       do_something_that_take_an_hour (дані);

       istance = новий object_with_very_painful_constructor (дані);

          якщо (istance недійсне) {
               повідомлення про помилку( );
                повернення;

          }
       connect_to_database ();
       get_some_other_data ();
       повернення;
    }

Можливо, перше "повернення" - це НЕ ТАК інтуїтивно, але це справді економить. Занадто багато "ідей" щодо чистих кодів, яким просто потрібно більше практики, щоб втратити свої "суб'єктивні" погані ідеї.

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