Тезисы из книги Мартина «Чистый код»
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) контейнеров для управления зависимостями.
- Гибкость в архитектуре: Стремление к слабой связанности и высокой связности модулей для улучшения адаптивности кода.
Recommended Posts
Запахи кода из книги Мартина «Чистый код»
21.01.2019