C# Удалить ненужные логические литералы, вредные эффекты или последствия?

Question

Разработчики иногда используют следующий синтаксис в коде,

if (isProductFlag == true) 

if (customerExist == true)  
..etc

Sonarqube предупреждает. Вопрос в том, что вышеупомянутый синтаксис отрицательно влияет, то есть влияет на скорость / производительность, вызывает ошибки, в значительной степени увеличивает время компиляции, ошибки в системе? Что-нибудь, что нужно опасаться для программы? Рассматривая отключение этого конкретного предупреждения Sonarqube, если не причинено вреда. Мы знаем, что приведенный выше синтаксис является излишним, он должен быть if (isProductFlag) или if (customerExist). Однако у каждого программиста свой стиль. Множество других проблем в программе, на которые мы можем обратить внимание в сроки: et c.

SonarQube: Удалите ненужные логические литералы.

Ресурс: Разве плохо явно сравнивать с булевыми константами, например, если (b == false) в Java?

Обновление: как это работает с логическими значениями, допускающими обнуление?

Answer 1

Компилятор Roslyn все равно оптимизирует такие литералы. Он удалит недоступный код, выполнит вычисления для констант времени компиляции, где это возможно, и т. Д. c. Можно с уверенностью сказать, что это не повлияет на сгенерированный код, и вы можете убедиться, что с декомпилятором - IL идентичен с или без избыточных констант .

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

if (customerExists)
{
    DoWork();
}

if (customerExists == true)
{
    DoWork();
}

"Если customerExists, DoWork" или, скорее, "Если customerExists равен true, DoWork" ? Какой из них, скорее всего, появится в качестве требования заказчика в проектной документации? Никто не говорит, как «Если дожди равны истине, я возьму зонтик» .

Две, линии, подобные этой, раздражают . Почему разработчик прямо заявляет, что это должно быть равно true? Что-то еще происходит, чего я не вижу? Я, вероятно, наведу курсор мыши на переменную, чтобы убедиться, что она даже логическая. Если что-то не нужно, сразу возникает вопрос: «Почему это здесь?» . Вы хотите, чтобы ваши разработчики не задавали такие вопросы. Намерение должно быть ясным.

Я думаю, я должен добавить, что последний, возможно, более противный. Это то, что Энди Хант и Дейв Томас назвали « разбитое окно » в своем превосходном «Pragmati c Programmer». Такие мелочи создают у разработчиков ощущение, что на самом деле никто не заботится о коде. Эта вещь необходима? Будь я проклят, если я знаю, кто-то написал это в возрасте go, лучше оставь все как есть. Это начинается с мелких вещей и накапливается со временем. Поначалу это может показаться педантичным, и я, конечно же, не пытаюсь закончить конец света - заставить вас думать, что весь ваш проект взломает sh и сгорит из-за нескольких логических литералов. Но , если никто не заботится об этом аспекте кода, почему он должен заботиться о следующем ?

Answer 2

Это чисто стиль, но предполагает, что ваш код не очень понятен:

if (productFlag == true)  

излишен и будет лучше обслуживаться с лучшими именами переменных:

if (hasProductFlag)
{
   //...
}

это также делает рефакторинг уточняется, если позже требуется, поскольку

if (hasProductFlag())

все еще более ясно, чем

if (hasProductFlag() == true)

Есть ли функциональная разница? Почти наверняка нет. Но это может уменьшить количество ошибок из-за большей ясности.

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