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

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

if((elementIndex < 0) || (MAX_ELEMENTS < elementIndex) || 
   (elementIndex == lastElementIndex)){
       ...
}

Він пропонує:

finished = ((elementIndex < 0) || (MAX_ELEMENTS < elementIndex));
repeatedEntry = (elementIndex == lastElementIndex);
if(finished || repeatedEntry){
   ...
}

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

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

Деякі мови, які не мають поняття "присвоєння" як такі, як Haskell, навіть вводять спеціалізовані конструкції, які дозволять вам використовувати техніку "дайте ім'я підвиразу" ( whereпункт у Haskell) - здається, це говорить про деякі популярність відповідної техніки! -)

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

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

Інші зрозуміють це і не знайдуть це дивним (за винятком тих, хто коли-небудь пише лише тисячі рядкових функцій, тобто).

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

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

Найбільшим для мене є, коли я бачу такий метод, як: DoSomeMethod(true); Чому для нього автоматично встановлюється значення true? Це набагато читабельніше, як

bool deleteOnCompletion = true;

DoSomeMethod(deleteOnCompletion);

Наданий зразок:

finished = ((elementIndex < 0) || (MAX_ELEMENTS < elementIndex));
repeatedEntry = (elementIndex == lastElementIndex);
if(finished || repeatedEntry){
   ...
}

Також можна переписати на використання методів, які покращують читабельність і зберігають логічну логіку (як зазначив Конрад):

if (IsFinished(elementIndex) || IsRepeatedEntry(elementIndex, lastElementIndex)){
   ...
}

...

private bool IsFinished(int elementIndex) {
    return ((elementIndex < 0) || (MAX_ELEMENTS < elementIndex));
}

private bool IsRepeatedEntry(int elementIndex, int lastElementIndex) {
    return (elementIndex == lastElementIndex);
}

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

Єдиний спосіб, як я міг бачити, що це йде не так, - це якщо логічний фрагмент не має імені, яке має сенс, і ім’я все одно вибрано.

//No clue what the parts might mean.
if(price>0 && (customer.IsAlive || IsDay(Thursday)))

=>

first_condition = price>0
second_condition =customer.IsAlive || IsDay(Thursday)

//I'm still not enlightened.
if(first_condition && second_condition)

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

i++; //increment i by adding 1 to i's previous value

Роблячи це

finished = ((elementIndex < 0) || (MAX_ELEMENTS < elementIndex));
repeatedEntry = (elementIndex == lastElementIndex);
if(finished || repeatedEntry){
   ...
}

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

Ви навіть можете визначити весь блок як предикат:

bool ElementBlahBlah? (elementIndex, lastElementIndex);

і робити більше речей (пізніше) у цій функції.

Якщо вираз є складним, тоді я або переміщую його до іншої функції, яка повертає booleg, isAnEveningInThePubAGoodIdea(dayOfWeek, sizeOfWorkLoad, amountOfSpareCash)або переглядаю код, щоб такий складний вираз не потрібен.

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

Так що:

if((elementIndex < 0) || (MAX_ELEMENTS < elementIndex) || 
   (elementIndex == lastElementIndex)){
   ...
}

Після перетворення стає:

if((elementIndex < 0) || (MAX_ELEMENTS < elementIndex) |
   (elementIndex == lastElementIndex)){
   ...
}

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

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

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

якщо метод вимагає повідомлення про успіх: (приклади в c #) Мені подобається використовувати

bool success = false;

щоб почати. код помилковий, поки я не зміню його на:

success = true;

то в кінці:

return success;

Думаю, це залежить від того, який стиль ви / ваша команда віддаєте перевагу. Рефакторинг "Ввести змінну" може бути корисним, але іноді ні :)

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

наприклад:

void DoSomeMethod(boolean needDelete) { ... }

// useful
boolean deleteOnCompletion = true;
if ( someCondition ) {
    deleteOnCompletion = false;
}
DoSomeMethod(deleteOnCompletion);

// useless
boolean shouldNotDelete = false;
DoSomeMethod(shouldNotDelete);

З мого досвіду, я часто повертався до деяких старих сценаріїв і замислювався, "про що, блін, я тоді думав?". Наприклад:

Math.p = function Math_p(a) {
    var r = 1, b = [], m = Math;
    a = m.js.copy(arguments);
    while (a.length) {
        b = b.concat(a.shift());
    }
    while (b.length) {
        r *= b.shift();
    }
    return r;
};

що не так інтуїтивно, як:

/**
 * An extension to the Math object that accepts Arrays or Numbers
 * as an argument and returns the product of all numbers.
 * @param(Array) a A Number or an Array of numbers.
 * @return(Number) Returns the product of all numbers.
 */
Math.product = function Math_product(a) {
    var product = 1, numbers = [];
    a = argumentsToArray(arguments);
    while (a.length) {
        numbers = numbers.concat(a.shift());
    }
    while (numbers.length) {
        product *= numbers.shift();
    }
    return product;
};

Я рідко створюю окремі змінні. Що я роблю, коли тести ускладнюються, я вкладаю ІФ та додаю коментарі. Подібно до

boolean processElement=false;
if (elementIndex < 0) // Do we have a valid element?
{
  processElement=true;
}
else if (elementIndex==lastElementIndex) // Is it the one we want?
{
  processElement=true;
}
if (processElement)
...

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