Практическое введение в охранные оговорки

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

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

Заявление об отказе от ответственности; мой взгляд на эту тему чисто субъективен.

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

Оговорки

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

Давайте разберем это определение на простые термины. Мы выполняем проверку предварительных условий целостности (в начале нашего кода), чтобы избежать каких-либо ошибок во время основного потока нашей логики.

В идеальном потоке (когда валидация правильная) мы хотим, чтобы основная логика нашей программы оставалась после всех проверок валидации.

Представим, что у нас есть веб-сайт, на котором есть зона премиум-покупок, доступная только платным клиентам и открытая только после 12 часов дня.

В реальном приложении мы, скорее всего, вернем некоторую форму исключения.

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

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

С защитными предложениями мы хотим следовать этой структуре:

Взяв эту структуру, мы можем реструктурировать предыдущий код следующим образом:

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

Этот подход отражает тот же самый точный логический поток, но, по моему мнению, а также по мнению других, это гораздо более чистый подход при работе с условной логикой.

Заключение

При кодировании мы всегда должны помнить о следующем вопросе: «Насколько легко будет поддерживать работу через 6 месяцев?»

Создавать решения проблемы в настоящее время - это здорово. Но как насчет будущего? Глупо не создавать программное обеспечение с расчетом на будущее.

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

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