8 способов правильно использовать условный оператор

Каким было бы программирование без условного оператора if? Вероятно, одна из наиболее часто используемых логических контрольных точек во всем программировании, без нее мы бы потерялись. К сожалению, как бы просто ни было добавить эту точку принятия решения в ваш код, она не застрахована от неправильного использования. За 20 лет работы программистом я видел несколько интересных ошибок других программистов. В произвольном порядке вот восемь примеров, основанных на реальных проблемах с «если» и возможных причинах их возникновения.

1) If / Else на логическом

Основы оператора if заключаются в переходе к блоку логики, когда условие оценивается как истинное. Дополнительной функцией является логический тип данных, который используется для указания истинности или ложности. Их часто используют вместе, но в этом примере этого быть не должно. Логика if / else не требуется, достаточно одного логического значения. Вот пример:

Возможные причины, почему это произошло:

  • В истинном или ложном сценариях могла быть дополнительная логика, но позже она была удалена. Оставшийся код не обновлялся, чтобы отразить это изменение.
  • Они не обращали внимания. Отключение во время кодирования - не редкость.
  • Логически код имеет смысл. Одного этого может быть достаточно для программиста, чтобы двигаться дальше, не меняя его к лучшему.

2) Повторяющиеся «если»

Использование одного и того же условия для оператора if снова и снова должно вызвать у вас в голове что-то, что что-то не так. Можно было бы надеяться. Этот пример находится в контексте шаблона Angular с использованием * ngIf’s, который является их версией встроенного оператора if. При их использовании применяются те же правила, и, как и большинство других вещей в кодировании, следует избегать повторяющейся логики. Вот пример плохого кода:

Возможные причины, почему это произошло:

  • Незнание того, что ng-container можно использовать с одним * ngIf вместо этого.
  • Им было бы легче думать о каждом блоке if отдельно.
  • Они забыли о принципе кодирования DRY (Don't Repeat Yourself).

3) Многословные ИФ даже со стенографией

В наши дни мой любимый ярлык - нулевой оператор объединения ??. До его появления в ES2020 я использовал оператор OR ||, но его ложное поведение не всегда применимо. Вот три примера инициализации объекта параметров, когда он имеет значение NULL.

Возможные причины, почему это произошло:

  • Некоторым нравится тернарный оператор. Я использую его как можно чаще, но для этого сценария есть варианты получше.
  • Несмотря на то, что операционная техника OR существует уже много лет, не всем она удобна. Его ложное поведение может быть неожиданным, если вы не будете осторожны.
  • Не все знают нулевой оператор объединения. Он был представлен в 2020 году, так что все еще довольно новый.

4) Логика назад, если / иначе

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

Возможные причины, почему это произошло:

  • Первый сценарий работает нормально, но они могли забыть, что это антипаттерн для поведения if / else. Случай else должен быть вариантом «поймать все остальное», а не наоборот.
  • Возможно, это было их мыслительным прогрессом, но программно есть правильный способ делать что-то.
  • Некоторым людям нравится в первую очередь думать о «неравных». Это могло быть вопросом предпочтения.

5) Ненужное If / Else для логического значения в виде строки

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

Возможные причины, почему это произошло:

  • Первый способ визуально более явный и, возможно, предпочтительнее видеть строковое представление логического значения.
  • Незнание того, что метод toString является жизнеспособным вариантом для логического сравнения.
  • Опять же, некоторым людям очень нравится тернарный оператор, и это считается сокращением. В этом случае есть более короткий и лучший способ.

6) Длинные блоки If / Else

Распространенный сценарий в кодировании - иметь несколько условных операторов подряд. Это нормально, когда условия нелегко связать, но когда вещи начинают выглядеть повторяющимися, им следует подумать об использовании оператора переключения.

Возможные причины, почему это произошло:

  • Не всем нравятся операторы переключения. Существует немного больше настроек для его структурирования, чем для объединения операторов if. Кроме того, необходимо учитывать поведение провала, добавляя операторы прерывания или возвраты.
  • Некоторые блоки if, возможно, уже существовали, и их было проще добавить. Они не хотели возиться с преобразованием в оператор switch.
  • Первый способ технически более гибкий, если к условиям if необходимо добавить другие критерии. Возможно, они ожидали, что позже добавят еще.

7) Вложенные если

Бывают случаи, когда вам нужно выполнить несколько условий if перед выполнением определенного действия. Здесь могут возникнуть вложенные if, но они могут быстро стать уродливыми. Логические && и || может помочь исправить чрезмерное вложение.

Возможные причины, почему это произошло:

  • Возможно, они не любят использовать логические операторы. Это было бы удивительно, поскольку они хорошо разбираются в компьютерных науках, но не все имеют опыт работы в сфере компьютерных наук.
  • Поведение двух сценариев одинаково, и они читаются почти одинаково. Однако второй вариант более лаконичен и требует меньше строк кода.
  • Иногда, когда есть несколько логических операторов и заключаются в скобки внутри условия if, его трудно читать. Первым путем могло быть естественное избегание этого сценария.

8) Ненужное If / Else для логического сравнения

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

Возможные причины, почему это произошло:

  • Тернарный оператор хорош, но знаете, что еще лучше? Не нужно его вообще использовать. Возможно, они просто действительно хотели использовать тернарный оператор.
  • Это могла быть ошибка копирования / вставки, и при наличии тернарного оператора они подумали, что им нужно поместить туда значения.
  • Честно говоря, придумать хорошее оправдание для этой ошибки - непростая задача.

Заключение

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

Спасибо за чтение и будьте добры к этим утверждениям if!