Если вы уже пытались покорить неприступную крепость «чистого кода», то знаете, что это совсем непросто. Мертвый код, неиспользуемые переменные, несоответствие типов, потенциально проблемные шаблоны… Нужно проследить за столькими вещами, что голова идет кругом, а руки опускаются. Она не ограничивается знаниями паттернов и принципов. Над кодом нужно попотеть, нужно стараться и испытывать неудачи.

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

Некоторые принципы

Чем больше вы будете использовать методологию «чистого» кода, тем меньше компилятор будет понимать, что вы делаете. Все в отдельных единицах трансляции, все скрыто за виртуальными функциями и т. Не имеет значения, насколько компилятор хорош, он мало что сможет сделать с такого рода кодом. Большая часть этих правил фактически не влияют на скорость выполнения вашего кода.

Я рекомендую вам изучить все доступные инструменты рефакторинга вашей IDE и поэкспериментировать с ними, чтобы понять, как они работают и насколько они будут вам полезны. Самым простым рефакторингом является переименование (Rename). Например, есть сущность с именем, которое вам не нравится, и вы хотите его изменить.

Прекращайте писать комментарии

Это значит, что вы можете выполнять некоторые действия перед тем, как изменения будут закоммичены и отправлены в удаленный репозиторий. В файле .eslintignore можно указать адреса, которые будут игнорироваться линтером, например, файлы git или конфигурация редактора кода. Вы можете добавлять правила во время выполнения, включать и выключать их, задавать отдельные предупреждения и ошибки. Слабая динамическая типизация JavaScript – причина многих ошибок. Этот язык не компилируется, поэтому для проверки кода приходится полностью выполнить его. Линтеры позволяют найти подозрительные места, не запуская каждый раз программу.

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

Книги

Если этого не делать, то слои архитектуры приложения становятся более связанными и тяжелее поддаются изменениям. В примере ниже нам нужно поменять код в большем количестве мест, чтобы нарисовать прямоугольник не на экране, а отправить на https://deveducation.com/ принтер. Любой дурак может написать код, понятный компьютеру. Хороший разработчик пишет код, понятный человеку. Для демонстрации инструментов рефакторинга я выбрал JetBrains IntelliJ. Но вы найдете подобные инструменты и в других IDE.

Чтобы избежать вышеупомянутых ошибок, можно обернуть/заменить примитивные типы на специальные типы, например enum. Код должен выполнять свою задачу и не делать ничего лишнего. Классы и методы, которые делают всё и сразу, очень сложно читать и обновлять.

Комментарии не маскируют плохой код

Но это будет непросто, так как эта сущность может использоваться во многих местах. Подумайте, что будущему читателю кода будет интересно, когда он встретит этот if? Ему нужно понять, что этот if проверяет, является ли год високосным (leap year). Но, вероятнее всего, его не будет волновать, как выполняется эта проверка. Если все-таки это будет интересно, то он может перейти к реализации этого метода. Убрав комментарий, мы невольно также разделили разные уровни абстракции в коде.

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

Подробнее о необходимости обновлений мы писали в аналитическом обзоре. Код должен соответствовать правилу DRY (Don’t repeat yourself с англ. — «не повторяйтесь»). Это означает, что любое изменение как написать код в одном участке не должно требовать изменений в других. Каждый язык программирования разработан с учетом разных операционных систем, платформ, стилей кодирования и предполагаемого использования.