0 added
0 removed
Original
2026-01-01
Modified
2026-02-26
1
<p>Свитч - очень простая конструкция, которую изучают программисты в самом начале своего пути. Она ни у кого не вызывает вопросов, но с ней связана одна интересная деталь, которую очень часто упускают из виду и, в итоге, используют свитч неправильно. Это дефолтное поведение.</p>
1
<p>Свитч - очень простая конструкция, которую изучают программисты в самом начале своего пути. Она ни у кого не вызывает вопросов, но с ней связана одна интересная деталь, которую очень часто упускают из виду и, в итоге, используют свитч неправильно. Это дефолтное поведение.</p>
2
<p>Представьте, что в приложении у нас есть заказ, который может находиться в определенных состояниях. Например, он может быть оплачен, доставлен, передан в службу доставки и так далее. И где-то есть логика, зависящая от этого состояния:</p>
2
<p>Представьте, что в приложении у нас есть заказ, который может находиться в определенных состояниях. Например, он может быть оплачен, доставлен, передан в службу доставки и так далее. И где-то есть логика, зависящая от этого состояния:</p>
3
<p>По логике приложения, в этом коде задействованы все возможные состояния, и на каждое из них есть свое поведение. При такой постановке switch не содержит дефолтного поведения.</p>
3
<p>По логике приложения, в этом коде задействованы все возможные состояния, и на каждое из них есть свое поведение. При такой постановке switch не содержит дефолтного поведения.</p>
4
<p>Однако линтер с нами не согласится. Практически во всех языках он начнет ругаться на то, что дефолт не определен. С этого момента есть два пути.</p>
4
<p>Однако линтер с нами не согласится. Практически во всех языках он начнет ругаться на то, что дефолт не определен. С этого момента есть два пути.</p>
5
<p>Начнем с неправильного. Программист думает, что линтер ошибается, и либо заглушает его, либо добавляет туда код, который ничего не делает. Например, возвращает null или просто содержит один break.</p>
5
<p>Начнем с неправильного. Программист думает, что линтер ошибается, и либо заглушает его, либо добавляет туда код, который ничего не делает. Например, возвращает null или просто содержит один break.</p>
6
<p>Так ли ошибается линтер? Путь, описанный выше, чисто механический. Он не учитывает семантику кода (привет, ментальное программирование) и порождает отложенные проблемы.</p>
6
<p>Так ли ошибается линтер? Путь, описанный выше, чисто механический. Он не учитывает семантику кода (привет, ментальное программирование) и порождает отложенные проблемы.</p>
7
<blockquote><p>Подписывайтесь на<a>канал Кирилла Мокевнина в Telegram</a>- чтобы узнать больше о программировании и профессиональном пути разработчика</p>
7
<blockquote><p>Подписывайтесь на<a>канал Кирилла Мокевнина в Telegram</a>- чтобы узнать больше о программировании и профессиональном пути разработчика</p>
8
</blockquote><p>Главный вопрос, который нужно задать себе в этом месте: "А в каком случае мы туда действительно попадем?" Таких вариантов несколько: программист ошибся в имени состояния либо добавилось новое состояние, на которое еще нет обработчика. Считаем ли мы такое поведение нормальным? В подавляющем большинстве случаев - нет. Это так называемая ошибка программирования. Если программист ошибся, значит программа работает неверно, и лучшим решением в данной ситуации будет максимально быстрое оповещение о проблеме. Это позволит локализовать проблему и отреагировать сразу, как только она появилась. В противном же случае программа может продолжать вести себя "почти" корректно. Иногда корректно, а иногда нет, и узнаем мы об этом, скорее всего, не сразу и, в худшем случае, от клиентов, когда уже возникнут более серьезные проблемы. То же самое касается добавления нового состояния. Наверняка оно потребует своей собственной обработки.</p>
8
</blockquote><p>Главный вопрос, который нужно задать себе в этом месте: "А в каком случае мы туда действительно попадем?" Таких вариантов несколько: программист ошибся в имени состояния либо добавилось новое состояние, на которое еще нет обработчика. Считаем ли мы такое поведение нормальным? В подавляющем большинстве случаев - нет. Это так называемая ошибка программирования. Если программист ошибся, значит программа работает неверно, и лучшим решением в данной ситуации будет максимально быстрое оповещение о проблеме. Это позволит локализовать проблему и отреагировать сразу, как только она появилась. В противном же случае программа может продолжать вести себя "почти" корректно. Иногда корректно, а иногда нет, и узнаем мы об этом, скорее всего, не сразу и, в худшем случае, от клиентов, когда уже возникнут более серьезные проблемы. То же самое касается добавления нового состояния. Наверняка оно потребует своей собственной обработки.</p>
9
<p>Перепишем switch с учетом вышесказанного:</p>
9
<p>Перепишем switch с учетом вышесказанного:</p>
10
<p>Уже значительно лучше, но все еще недостаточно. Любой код, который связан с ошибками, должен помогать отладке. Код выше этого не делает. Да, мы увидим ошибку сразу, но как мы узнаем, а что там было? Куда смотреть? Какое состояние неверное? Исследования потребуют дополнительного времени. Гораздо лучше помочь себе сразу:</p>
10
<p>Уже значительно лучше, но все еще недостаточно. Любой код, который связан с ошибками, должен помогать отладке. Код выше этого не делает. Да, мы увидим ошибку сразу, но как мы узнаем, а что там было? Куда смотреть? Какое состояние неверное? Исследования потребуют дополнительного времени. Гораздо лучше помочь себе сразу:</p>
11
<p>Если кратко, то общее правило такое: если логика кода предполагает поведение по умолчанию, то реализуйте в дефолте необходимую логику, если нет, то это ошибочная ситуация, которую надо обработать, выбросив исключение.</p>
11
<p>Если кратко, то общее правило такое: если логика кода предполагает поведение по умолчанию, то реализуйте в дефолте необходимую логику, если нет, то это ошибочная ситуация, которую надо обработать, выбросив исключение.</p>
12
<h3>Дополнительные материалы:</h3>
12
<h3>Дополнительные материалы:</h3>
13
<ul><li><a>Проектирование параметров функций</a></li>
13
<ul><li><a>Проектирование параметров функций</a></li>
14
<li><a>Проектирование функций</a></li>
14
<li><a>Проектирование функций</a></li>
15
</ul>
15
</ul>