Інвертування твердження IF

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

Скажімо, у мене є цей код:

foreach (someObject in someObjectList) 
{
    if(someObject != null) 
    {
        someOtherObject = someObject.SomeProperty;
    }
}

І ReSharper запропонує зробити це:

foreach (someObject in someObjectList)
{
    if(someObject == null) continue;
    someOtherObject = someObject.SomeProperty;
}

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

Моє запитання: окрім особистих уподобань чи читабельності, чи є причина зменшити гніздування? Чи є різниця в продуктивності чи щось інше, про що я, можливо, не знаю?

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

Ми є лише людьми, і тримати в голові кілька речей одночасно важко.

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

Не уникайте негативів. Люди смокчуть, як їх розбирають, навіть коли ЦП їх любить.

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

foo != null, на жаль, став ідіомою. Я майже не помічаю окремих частин. Я дивлюся на це і просто думаю: "о, це безпечно робити fooзараз".

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

Однак, що ви нам дали:

foreach (someObject in someObjectList)
{
    if(someObject == null) continue;
    someOtherObject = someObject.SomeProperty;
}

Що навіть структурно не однакове!

foreach (someObject in someObjectList)
{
    if(someObject == null) continue;
    someOtherObject = someObject.SomeProperty;

    if(someGlobalObject == null) continue;
    someSideEffectObject = someGlobalObject.SomeProperty;
}

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

Тож вибачте, можливо, ReSharper має рацію запропонувати це 90% часу, але я вважаю, що ви знайшли кутовий випадок, коли це найкраще ігнорувати. Інструменти просто непогані в навчанні того, що таке читабельний код. Запитайте у людини. Зробіть експертну перевірку. Але не слід сліпо слідувати інструменту.

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

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

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

foreach (someObject in someObjectList.where(i=>i != null))
{
    someOtherObject = someObject.SomeProperty;
}

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

foreach (someObject in someObjectList) 
{
    if(someObject != null) 
    {
        someOtherObject = someObject.SomeProperty;
        if(someObject.x > 5) 
        {
            x ++;
            if(someObject.y > 5) 
            {
                x ++;
            }
        }
    }
}

Найгірше, коли у вас є обоє

foreach (someObject in someObjectList) 
{
    if(someObject != null) 
    {
        someOtherObject = someObject.SomeProperty;
        if(someObject.x > 5) 
        {
            x ++;
            if(someObject.y > 5) 
            {
                x ++;
                return;
            }
            continue;
        }
        someObject.z --;
        if(myFunctionWithSideEffects(someObject) > 6) break;
    }
}

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

foreach (someObject in someObjectList)
{
    if(someObject == null) continue;
    someOtherObject = someObject.SomeProperty;

    ...  imagine that there is some code here ...

    // added later by a Junior Developer
    doSomeOtherFunction(someObject);
}

Ви хочете , щоб зателефонувати doSomeOtherFunction()за всьому SomeObject, або тільки якщо не нуль? З оригінальним кодом у вас є можливість, і він зрозуміліший. З тим, що continueможна забути "о, так, там ми пропустили нулі", і ви навіть не маєте можливості називати це для всіх деяких об'єктів, якщо ви не ставите цей виклик на початку методу, який може бути неможливим або правильним з інших причин.

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

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

Ідея полягає у якнайшвидшому поверненні. Рано returnв петлі стає рано continue.

Багато хороших відповідей на це питання: Чи слід повернутися з функції рано чи використовувати оператор if?

Зауважте, що поки питання закрите на основі думки, 430+ голосів виступають за дострокове повернення, ~ 50 голосів - це "це залежить", а 8 - проти дострокового повернення. Тож існує виключно сильний консенсус (або це, або я погано рахую, що правдоподібно).

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

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

Ми часто інвертуємось ifsу моїй роботі та використовуємо інший фантом. Раніше це було досить часто, коли під час перегляду PR я міг зазначити, як мій колега міг зняти три рівні гніздування! Це трапляється рідше, оскільки ми розгортаємо свої ifs.

Ось іграшковий приклад того, що можна розгорнути

function foobar(x, y, z) {
    if (x > 0) {
        if (z != null && isGamma(y)) {
            // ~10 lines of code
            // return something
        }
        else {
           return y
        }
    }
    else {
      return y + z
    }
}

Такий код, де є ОДИН цікавий випадок (де решта - це просто повернення або невеликі блоки операторів). Банально переписати вищезгадане як

function foobar(x, y, z) {
    if (x <=0) {
        return y + z
    }
    if (z == null || !isGamma(y) {
       return y
    }
    // ~ 10 lines of code
    // return something
}

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

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

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

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

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

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

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

for(obj in objectList) {
    if(obj == null) continue;
    if(obj.getColour().equals(Color.BLUE)) {
        // Handle blue objects
    } else {
        // Handle non-blue objects
    }
}

Зауважте, що в Java Streams або інших функціональних ідіомах ви можете відокремити фільтрування від циклу, використовуючи:

items.stream()
    .filter(i -> (i != null))
    .filter(i -> i.getColour().equals(Color.BLUE))
    .forEach(i -> {
        // Process blue objects
    });

Між іншим, це одне із речей, які мені подобаються у перевернутому Perl, якщо ( unless) застосовується до одиничних висловлювань, що дозволяє наступний вид коду, який мені дуже легко читати:

foreach my $item (@items) {
    next unless defined $item;
    carp "Only blue items are supported! Failed on item $item" 
       unless ($item->get_colour() eq 'blue');
    ...
}