Я наткнулся на следующее условие в программе, которую я перенял у другого разработчика:
if (obj.Performance <= LOW_PERFORMANCE)
{
obj.NeedsChange = true;
}
else
{
obj.NeedsChange = false;
}
Я считаю, что этот код является избыточным и безобразным, поэтому я изменил его на то, что мне показалось простым логическим назначением, основанным на сравнении:
obj.NeedsChange = obj.Performance <= LOW_PERFORMANCE;
Увидев это, кто-то, просматривая мой код, заметил, что, хотя мои изменения функционально верны, это может смутить кого-то, кто смотрит на них. Он считает, что использование троичного оператора делает это назначение более ясным, тогда как мне не нравится добавление более избыточного кода:
obj.NeedsChange = (obj.Performance <= LOW_PERFORMANCE) ? true : false;
Он рассуждает о том, что делать что-то самым кратким способом не стоит, если это заставляет другого разработчика останавливаться и ломать голову над тем, что вы сделали.
Реальный вопрос здесь заключается в том, какой из этих трех методов присвоения значения логическому значению obj.NeedsChange
является наиболее понятным и наиболее поддерживаемым?
источник
Ответы:
Я предпочитаю 2, но я мог бы пойти на небольшую корректировку:
Для меня скобки облегчают анализ строки и сразу дают понять, что вы присваиваете результат сравнения, а не выполняете двойное назначение. Я не уверен, почему это так (поскольку я не могу придумать язык, в котором круглые скобки фактически препятствуют двойному назначению), но если вы должны удовлетворить своего рецензента, возможно, это будет приемлемый компромисс.
источник
a = b == c
, вы имели в виду назначить bool или вы имели в виду назначить c для b и a.Вариант 1 легко понять, но это его единственное преимущество. Я автоматически предполагаю, что любой, кто пишет так, на самом деле не понимает, что такое булевы значения, и будет писать аналогично инфантильный код во многих других отношениях.
Вариант 2 - это то, что я всегда пишу и ожидаю прочитать. Я думаю, что любой, кого смущает эта идиома, не должен быть профессиональным автором программного обеспечения.
Вариант 3 сочетает в себе недостатки как 1, так и 2.
источник
В любое время код является более сложным, чем он должен вызывать "что это должно делать?" запах в читателе.
Например, первый пример заставляет меня задуматься: «Были ли другие функции в операторе if / else в какой-то момент, который был удален?»
Пример (2) прост, понятен и делает именно то, что нужно. Я прочитал это и сразу понял, что делает код.
Дополнительный пух в (3) заставил бы меня задуматься, почему автор написал это так (2). Там должна быть причина, но в данном случае не кажется , нет, так что это не полезно вообще и труднее читать , потому что синтаксис предполагает , что - то настоящее , которое не существует. Попытка узнать, что присутствует (когда ничего нет) затрудняет чтение кода.
источник
Легко видеть, что Вариант 2 и Вариант 1 связаны посредством ряда очевидных и простых рефакторингов:
Здесь у нас есть ненужное дублирование кода, мы можем выделить назначение:
или написано более кратко:
Теперь должно быть сразу очевидно, что это будет присваивать значение true, если условие истинно, и присваивать значение false, если условие ложно, поэтому я просто назначу значение условия, т.е. оно эквивалентно
Варианты 1 и 3 - это типичный код новичка, написанный кем-то, кто не понимает, что такое возвращаемое значение сравнения.
источник
В то время как ваше программирование должно стремиться к явному, а не к неявному «как будто парень, который в конечном итоге будет поддерживать ваш код, будет жестоким психопатом, который знает, где вы живете», вы можете предположить несколько основных вещей , в которых ваш психопреемник будет компетентен.
Одним из них является синтаксис языка, который он использует.
Это очень понятно для любого, кто знает синтаксис C / C ++ / C # / Java / Javascript.
Это также намного более читабельно, чем 8 строк.
и менее подвержен ошибкам
И это лучше, чем добавлять ненужные символы, как будто вы наполовину забыли синтаксис языка:
Я думаю, что в C-подобном синтаксисе многих языков много неправильного: непоследовательный порядок операций, непоследовательная ассоциативность слева / справа, перегруженное использование символов, дублирование фигурных скобок / отступов, троичные операторы, инфиксная запись и т. Д.
Но решение состоит не в том, чтобы придумать свою собственную версию. Так лежит безумие, так как каждый создает свой.
Как правило, первое, что делает код Real World TM нечитаемым, это его количество.
Между непатологической 200-строчной программой и тривиально идентичной 1600-строчной программой, более короткую почти всегда будет легче разобрать и понять. Я бы приветствовал ваши изменения в любой день.
источник
Большинство разработчиков смогут понять 2-й вид с первого взгляда. На мой взгляд, упрощение, как в 1-м классе, просто не нужно.
Вы можете улучшить читабельность, добавив пробелы и фигурные скобки, такие как:
или же
как упомянул Джейкоб Рэйл.
источник