Должны ли программисты использовать логические переменные для документирования своего кода?

Разбиение слишком вложенного и сложного выражения на более простые подвыражения, присваиваемые локальным переменным, а затем снова объединяемые, является довольно распространенным и популярным методом — совершенно независимо от того, являются ли подвыражения и/или общее выражение логическими или логическими. почти любой другой тип. При правильно подобранных именах такая изящная декомпозиция может повысить читабельность, и хороший компилятор без труда сгенерирует код, эквивалентный оригинальному сложному выражению.

Некоторые языки, которые не имеют концепции «присваивания» как таковой, такие как 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);

и делать больше вещей (позже) в этой функции.

Если выражение сложное, я либо перемещаю его в другую функцию, которая возвращает bool, например, isAnEveningInThePubAGoodIdea(dayOfWeek, sizeOfWorkLoad, amountOfSpareCash), либо пересматриваю код, чтобы такое сложное выражение не требовалось.

Помните, что таким образом вы вычисляете больше, чем необходимо. Из-за удаления условий из кода вы всегда вычисляете их оба (без короткого замыкания).

Чтобы:

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

После преобразования становится:

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

В большинстве случаев это не проблема, но все же в некоторых случаях это может означать ухудшение производительности или другие проблемы, например. когда во втором выражении вы предполагаете, что первое не удалось.

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

Лично я считаю, что это отличная практика. Его влияние на выполнение кода минимально, но ясность, которую он может обеспечить при правильном использовании, бесценна, когда дело доходит до поддержки кода позже.

если метод требует уведомления об успехе: (примеры на С#) мне нравится использовать метод

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;
};

Я редко создаю отдельные переменные. Что я делаю, когда тесты усложняются, так это встраиваю IF и добавляю комментарии. Нравиться

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)
...

Признанный недостаток этого метода заключается в том, что следующий программист, который придет, может изменить логику, но не удосужится обновить комментарии. Я предполагаю, что это общая проблема, но я много раз видел комментарий, в котором говорится «подтвердить идентификатор клиента», а в следующей строке проверяется номер детали или что-то в этом роде, и мне остается задаться вопросом, где клиент приходит ид.