Введення додаткових локальних змінних як заміна коментарів

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

Наприклад:

bool easyUnderstandableIsTrue = (/* rather cryptic boolean expessions */);

if(easyUnderstandableIsTrue)
{
    // ...
}

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

Яка вартість додаткової змінної? У більшості мов жодна, як у складених, так і в інтерпретованих мовах.

Яка користь від цього?

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

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

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

    // Find if the user is an actual author in order to allow her to edit the message.
    if (currentUser.isAdministrator || (message.author == currentUser && !message.locked))

Вираз, ймовірно, почався з if (message.author == currentUser), а потім перетворився на обробку випадку заблокованих повідомлень та адміністраторів, яким не потрібно бути авторами та не хвилюватися про заблоковані речі; проте коментар не відобразив жодної із цих змін.

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

Зауважте, якщо ваш булевий вираз стає надмірно складним: ²

• Витягніть його окремим методом і:
• Перетворюйте його на кілька простих булевих виразів.

Приклад вище:

class Message
{
    ...
    public boolean canBeEditedBy(User user)
    {
        ...
        if (user.isAdministrator) {
            return true;
        }

        return this.author == user && !this.locked;
    }
}

...
if (message.canBeEditedBy(currentUser)) // See? Much more readable now!
{
    ...
}

^{¹ Джерело: моє власне спостереження за моїми однолітками, що розробляють переважно програмне забезпечення для бізнесу; YMMV. Справжнє дослідження може показати різні результати. Особисто я вважаю, що коли розробники читають код, вони зосереджуються на коді , а коментарі - це документація, а не код; тому вони, як правило, не читають коментарів, тому важко буде очікувати їх оновлення.}

^{² Занадто складний поріг визначається простою формулою: якщо половина розробників, які переглядають ваш код, висловлюють наміри вбити вас, поріг буде досягнуто. Булевий вираз вище досить простий, щоб вимагати рефакторингу; однак чотири частини поспіль if ((a && b) || (c && d))зробили б її потенційно реконструктивною. Зауважте, що якщо вираз плоский, кількість частин здебільшого не має значення: if (a || b || c || d || ... || z)є достатньо читабельною.}