IT заметки по программированию
IT заметки по программированию
IT заметки по программированию
IT заметки по программированию

Тезисы из книги Мартина «Чистый код»

1. Понятие «Чистого кода»

  • Определение чистого кода: Чистый код — это код, который легко читать и понимать. Он должен быть простым, точным и минимально возможным для выполнения своих задач.
  • Качества чистого кода: Понятность, возможность сопровождения, отсутствие дублирования, наличие выразительных имен и структур, минимизация зависимости между модулями.
  • Цель чистого кода: Сделать код таким, чтобы он выглядел так, как если бы его писал человек, которому не было безразлично.

2. Имена

  • Значение имен: Хорошие имена переменных, функций и классов облегчают понимание и делают код самодокументированным.
  • Выразительность: Имена должны передавать смысл и назначение сущности, а не быть загадочными сокращениями.
  • Консистентность: Использование согласованных имен в одном контексте помогает избежать путаницы.
  • Примеры:
    • Плохое имя: d (непонятно, что это)
    • Хорошее имя: daysSinceLastUpdate (сразу ясно, что это количество дней с последнего обновления).

3. Функции

  • Маленькие функции: Функции должны быть короткими, обычно не более 20 строк. Маленькие функции легче читать, тестировать и сопровождать.
  • Принцип единственной ответственности: Функция должна делать только одну вещь и делать это хорошо.
  • Избегайте побочных эффектов: Функции должны быть чистыми, то есть они должны возвращать одно и то же значение при одинаковых входных данных, не изменяя внешние состояния.
  • Именование функций: Имя функции должно объяснять, что она делает, например, calculateTotal() вместо calc().
  • Количество параметров: Старайтесь минимизировать количество параметров, не более двух-трех.

4. Комментарии

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

5. Форматирование кода

  • Читаемость: Форматирование — это способ сделать код визуально доступным, разделяя логические блоки и выделяя ключевые части.
  • Отступы и пробелы: Используйте отступы и пустые строки для улучшения читаемости, например, отделение логически связанных блоков.
  • Единообразие: Следование единому стилю форматирования в проекте облегчает совместную работу над кодом.

6. Обработка ошибок

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

7. Объекты и структуры данных

  • Инкапсуляция: Скройте детали реализации, предоставляя только необходимые интерфейсы для взаимодействия.
  • Разделение ответственности: Объекты должны предоставлять поведение, а структуры данных — только данные. Это упрощает использование и тестирование.
  • Пример:
    • Объекты: инкапсулируют данные и предоставляют методы для работы с ними.
    • Структуры данных: простые структуры, которые предоставляют доступ к данным без поведения.

8. Тестирование

  • Значение тестов: Хорошие тесты позволяют уверенно изменять и рефакторить код, зная, что ошибки будут быстро обнаружены.
  • Понятные и простые тесты: Тесты должны быть такими же чистыми и понятными, как и основной код. Если тесты сложны, они не выполняют свою функцию.
  • Тестирование через TDD (Test-Driven Development): Писать тесты до написания кода, чтобы проектировать код через тесты.

9. Чистота классов

  • Single Responsibility Principle (SRP): Каждый класс должен выполнять одну конкретную задачу.
  • Минимизация ответственности: Чем меньше обязанностей у класса, тем проще его использовать и тестировать.
  • Классы должны быть маленькими: Маленькие классы с четко определенными обязанностями облегчают навигацию и понимание системы.

10. Избавление от мусора

  • Рефакторинг: Постоянное улучшение и очистка кода, удаление мертвого кода, дублирования и других «запахов».
  • Технический долг: Избавление от технического долга через постоянный рефакторинг уменьшает количество ошибок и снижает затраты на поддержку.
  • Инструменты для рефакторинга: Используйте автоматические инструменты и техники, такие как автоматическое форматирование и статический анализ кода.

11. Солидарность с SOLID-принципами

  • SRP: Принцип единственной ответственности.
  • OCP (Open-Closed Principle): Классы должны быть открыты для расширения, но закрыты для модификации.
  • LSP (Liskov Substitution Principle): Подклассы должны полностью соответствовать поведению своих суперклассов.
  • ISP (Interface Segregation Principle): Клиенты не должны зависеть от интерфейсов, которые они не используют.
  • DIP (Dependency Inversion Principle): Модули высокого уровня не должны зависеть от модулей низкого уровня, оба должны зависеть от абстракций.

12. Сила рефакторинга

  • Постепенные улучшения: Маленькие, частые изменения лучше больших и редких, так как снижают риск ошибок.
  • Постоянная чистка: Регулярная работа по рефакторингу помогает поддерживать код в хорошем состоянии.
  • Безопасный рефакторинг: Использование автоматизированных тестов для проверки работоспособности кода после изменений.

13. Минимизация зависимости

  • Избегайте жестких зависимостей: Жесткие связи между модулями затрудняют изменения. Используйте интерфейсы и абстракции для ослабления связей.
  • Dependency Injection: Использование DI и IOC (Inversion of Control) контейнеров для управления зависимостями.
  • Гибкость в архитектуре: Стремление к слабой связанности и высокой связности модулей для улучшения адаптивности кода.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *