ключевых вывода
1. Чистый код читаем, прост и выразителен
Чистый код всегда выглядит так, будто его написал человек, которому не безразлично.
Ясность — это ключ. Чистый код характеризуется своей читаемостью и простотой. Он должен быть понятен другим программистам, чтобы они могли его понять, изменить и поддерживать. Это включает в себя использование ясных и значимых имен, небольшие и сосредоточенные функции и логичную организацию кода.
Выразительный код передает намерение. Чистый код должен четко выражать намерение программиста без необходимости в обширных комментариях. Это достигается за счет хорошо подобранных имен, небольших функций, которые выполняют одну задачу, и ясной общей структуры. Сам код должен рассказывать историю, облегчая читателям следование логике и цели каждого компонента.
Непрерывное улучшение — это важно. Написание чистого кода — это постоянный процесс, требующий внимания и рефакторинга. Программисты должны следовать правилу скаута: «Оставляйте место более чистым, чем вы его нашли». Это означает, что нужно всегда искать возможности для улучшения ясности и структуры кода, даже в мелочах, с каждым изменением или добавлением.
2. Значимые имена повышают ясность и поддерживаемость кода
Имя переменной, функции или класса должно отвечать на все важные вопросы. Оно должно объяснять, почему оно существует, что делает и как используется.
Выбирайте описательные имена. Имена должны быть самодостаточными и раскрывать намерение за переменными, функциями и классами. Избегайте однобуквенных имен, аббревиатур или загадочных кодов, которые требуют умственного сопоставления для понимания их назначения.
Используйте соглашения об именовании последовательно. Применяйте и придерживайтесь стандартных соглашений об именовании для вашего языка программирования и команды. Это включает в себя:
- CamelCase для имен классов (например, CustomerOrder)
- camelCase для имен переменных и функций (например, totalAmount)
- ALL_CAPS для констант (например, MAX_SIZE)
Избегайте дезинформации и шума. Не используйте имена, которые могут быть вводящими в заблуждение или запутанными. Например, избегайте использования 'list' в имени переменной, если это не список. Также избегайте избыточных или бессмысленных слов в именах, таких как 'data' или 'info', если они не добавляют ценности.
3. Функции должны быть маленькими, выполнять одну задачу и работать на одном уровне абстракции
Функции должны делать одно. Они должны делать это хорошо. Они должны делать это только.
Держите функции маленькими. Идеальные функции не должны превышать 20 строк. Это делает их более читаемыми, понятными и поддерживаемыми. Меньшие функции также легче точно называть, тестировать и повторно использовать.
Принцип единственной ответственности. Каждая функция должна иметь одну четко определенную цель. Если функция выполняет несколько задач, ее следует разбить на более мелкие, более сосредоточенные функции. Это улучшает читаемость и делает код более модульным и легким для изменения.
Последовательный уровень абстракции. Внутри функции все операции должны находиться на одном уровне абстракции. Смешивание высокоуровневой логики с низкоуровневыми деталями делает функции трудными для понимания и поддержки. Используйте технику рефакторинга «Извлечь метод», чтобы разделить разные уровни абстракции на отдельные функции.
4. Комментарии должны быть минимальными и действительно необходимыми
Правильное использование комментариев — это компенсация за нашу неспособность выразить себя в коде.
Код должен быть самодостаточным. Хорошо написанный код с ясными именами и структурой часто устраняет необходимость в комментариях. Прежде чем добавлять комментарий, подумайте, можете ли вы рефакторить код, чтобы сделать его намерение более ясным.
Используйте комментарии с умом. Хорошие комментарии объясняют, почему что-то сделано, а не как это сделано. Они должны предоставлять контекст или разъяснение, которое нельзя выразить только в коде. Полезные комментарии включают в себя:
- Юридические комментарии (авторские права, лицензирование)
- Объяснение намерений или алгоритмов
- Предупреждения о последствиях
- Комментарии TODO (используйте их экономно)
Избегайте избыточных или вводящих в заблуждение комментариев. Не пишите комментарии, которые просто повторяют то, что код уже ясно говорит. Устаревшие или неверные комментарии хуже, чем отсутствие комментариев, так как они могут ввести читателей в заблуждение. Регулярно проверяйте и обновляйте комментарии вместе с кодом, который они описывают.
5. Правильное форматирование улучшает читаемость кода
Форматирование кода — это о коммуникации, а коммуникация — это первоочередная задача профессионального разработчика.
Последовательный стиль имеет значение. Установите и следуйте последовательному стилю форматирования по всему вашему коду. Это включает в себя:
- Отступы
- Переносы строк
- Размещение скобок
- Пробелы вокруг операторов и ключевых слов
Вертикальное форматирование. Организуйте код вертикально для повышения читаемости:
- Держите связанные концепции близко друг к другу
- Разделяйте несвязанные концепции
- Объявляйте переменные рядом с их использованием
- Размещайте зависимые функции рядом друг с другом
Горизонтальное форматирование. Держите строки разумной длины (обычно 80-120 символов), чтобы избежать необходимости горизонтальной прокрутки. Разбивайте длинные выражения на несколько строк логичным образом. Используйте пробелы для разделения логических блоков внутри строки.
6. Объекты и структуры данных служат разным целям
Объекты скрывают свои данные за абстракциями и открывают функции, которые работают с этими данными. Структуры данных открывают свои данные и не имеют значительных функций.
Объекты против структур данных. Объекты инкапсулируют данные и открывают поведение через методы. Они хороши для добавления новых типов (классов) без изменения существующего поведения. Структуры данных, с другой стороны, открывают данные и не имеют значительного поведения. Они хороши для добавления новых поведений без изменения существующих типов данных.
Выбирайте правильный подход. Используйте объекты, когда хотите часто добавлять новые типы, но сохранять поведение стабильным. Используйте структуры данных, когда хотите часто добавлять новые поведения, но сохранять типы стабильными. Понимание этого различия помогает в проектировании более гибких и поддерживаемых систем.
Закон Деметры. Для объектов следуйте Закону Деметры: метод должен вызывать методы только на:
- Объекте самом
- Его параметрах
- Любых объектах, которые он создает
- Его прямых компонентах
Этот принцип помогает уменьшить связанность между различными частями системы.
7. Обработка ошибок должна быть чистой и информативной
Обработка ошибок важна, но если она затеняет логику, это неправильно.
Используйте исключения вместо кодов ошибок. Исключения предоставляют более чистый способ обработки ошибок по сравнению с традиционными кодами ошибок. Они отделяют логику обработки ошибок от основного кода, делая оба более понятными и поддерживаемыми.
Создавайте информативные сообщения об ошибках. Сообщения об ошибках должны предоставлять достаточно контекста, чтобы понять, что пошло не так и где. Включайте соответствующие детали, такие как:
- Какое действие пытались выполнить
- Какой конкретно произошла ошибка
- Любые соответствующие значения или информацию о состоянии
Сначала пишите блоки try-catch-finally. При написании кода, который может вызывать исключения, начните с написания блоков try-catch-finally. Это помогает гарантировать, что код устойчив к ошибкам с самого начала и что случаи ошибок должным образом учитываются.
8. Модульные тесты имеют решающее значение для поддержания чистого кода
Код тестов так же важен, как и производственный код.
Пишите тесты первыми. Следуйте практике разработки через тестирование (TDD):
- Напишите неудачный тест
- Напишите минимальный код, чтобы пройти тест
- Рефакторите код, сохраняя тест проходящим
Этот подход гарантирует, что ваш код тестируем с самого начала и помогает продвигать хорошее проектирование.
Держите тесты чистыми. Применяйте те же стандарты чистоты к вашему тестовому коду, что и к производственному. Чистые тесты:
- Читаемы
- Поддерживаемы
- Достоверны
Следуйте принципам F.I.R.S.T для тестов:
- Быстрые: тесты должны выполняться быстро
- Независимые: тесты не должны зависеть друг от друга
- Повторяемые: тесты должны быть повторяемыми в любой среде
- Самопроверяемые: тесты должны иметь булевый вывод (успех/неудача)
- Своевременные: тесты должны писаться непосредственно перед производственным кодом
9. Классы должны быть маленькими, сосредоточенными и следовать принципу единственной ответственности
Первое правило классов — они должны быть маленькими. Второе правило классов — они должны быть еще меньше.
Держите классы сосредоточенными. Класс должен иметь одну четко определенную ответственность. Если вы не можете описать цель класса примерно за 25 слов, не используя «и» или «или», вероятно, он делает слишком много.
Стремитесь к высокой когезии. Методы и переменные внутри класса должны быть тесно связаны и работать вместе для выполнения ответственности класса. Низкая когезия часто указывает на то, что класс пытается сделать слишком много и его следует разделить.
Принцип открытости-закрытости. Проектируйте классы так, чтобы они были открыты для расширения, но закрыты для изменения. Это часто включает в себя использование абстракций и интерфейсов, чтобы позволить добавлять новую функциональность без изменения существующего кода.
10. Параллелизм требует тщательного проектирования и реализации
Написание чистых параллельных программ — это сложно — очень сложно.
Понимание проблем параллелизма. Параллельное программирование вводит сложности, такие как:
- Условия гонки
- Взаимные блокировки
- Проблемы жизнеспособности
- Влияние на производительность
Держите код, связанный с параллелизмом, отдельно. Изолируйте код, который имеет дело с параллелизмом. Это упрощает понимание, тестирование и поддержку как параллельных, так и непараллельных частей вашей системы.
Используйте существующие библиотеки и фреймворки. Используйте хорошо протестированные библиотеки и фреймворки для параллелизма (например, java.util.concurrent в Java), а не пытайтесь реализовать низкоуровневый контроль параллелизма самостоятельно. Эти инструменты были оптимизированы и тщательно протестированы для распространенных паттернов параллелизма.
Пишите тщательные тесты. Тестирование параллельного кода сложно, но крайне важно. Пишите тесты, которые:
- Создают несколько потоков
- Варьируют время и расписание
- Запускаются много раз, чтобы увеличить вероятность выявления случайных проблем
- Используют инструменты, такие как санитайзеры потоков и статические анализаторы, чтобы помочь выявить потенциальные ошибки параллелизма.
Последнее обновление:
FAQ
What's Clean Code: A Handbook of Agile Software Craftsmanship about?
- Focus on Software Craftsmanship: The book emphasizes the importance of writing clean, maintainable code as a hallmark of professionalism in software development.
- Principles and Practices: It outlines various principles, patterns, and practices that help programmers write code that is not only functional but also easy to read and understand.
- Real-World Examples: Numerous examples of both good and bad code are included, demonstrating how to transform messy code into clean code through refactoring and disciplined practices.
Why should I read Clean Code by Robert C. Martin?
- Improve Coding Skills: Reading the book can significantly enhance your programming skills by teaching you how to write code that is easier to maintain and understand.
- Professional Development: It is a valuable resource for anyone looking to advance their career in software development, instilling a mindset of craftsmanship and quality.
- Practical Advice: The book provides practical advice that can be applied immediately in your coding practices, making it a useful guide for both novice and experienced programmers.
What are the key takeaways of Clean Code?
- Meaningful Names: The book stresses the importance of using intention-revealing names for variables, functions, and classes to enhance code readability and maintainability.
- Small Functions: Functions should be small and focused on a single task, adhering to the principle of "Do One Thing" to improve clarity and reduce complexity.
- Error Handling: Martin advocates for using exceptions rather than return codes for error handling, which helps keep the main logic of the code clean and unobscured.
What are the best quotes from Clean Code and what do they mean?
- "Clean code is a matter of discipline.": This quote emphasizes that writing clean code requires consistent effort and adherence to best practices, rather than relying on luck or talent alone.
- "Comments do not make up for bad code.": This highlights the idea that if code is poorly written, no amount of commenting can compensate for its lack of clarity and structure.
- "Leave the campground cleaner than you found it.": This metaphor encourages developers to improve the codebase with every change, ensuring that the code remains clean and maintainable over time.
How does Clean Code define clean code?
- Readable and Understandable: Clean code is defined as code that is easy to read and understand, allowing other developers to quickly grasp its purpose and functionality.
- Minimal Complexity: It should have minimal complexity, with each function and class focused on a single responsibility, making it easier to test and maintain.
- Well-Structured: Clean code is well-structured, following consistent formatting and naming conventions that enhance its clarity and reduce the cognitive load on the reader.
What is the Boy Scout Rule in Clean Code?
- Continuous Improvement: The Boy Scout Rule states that developers should "leave the campground cleaner than you found it," meaning that every time you work on code, you should strive to improve it.
- Small Changes Matter: This can be as simple as renaming a variable for clarity or refactoring a small function, which contributes to the overall cleanliness of the codebase.
- Professional Responsibility: Adhering to this rule reflects a professional attitude towards code quality and maintenance, fostering a culture of continuous improvement within a team.
What is the Single Responsibility Principle (SRP) in Clean Code?
- Definition of SRP: The SRP states that "a class should have one, and only one, reason to change." This means that each class should focus on a single responsibility or functionality.
- Benefits of SRP: Adhering to SRP leads to better organization of code, making it easier to understand, test, and maintain. It reduces the risk of changes in one area affecting unrelated parts of the code.
- Implementation Guidance: Martin provides practical advice on how to identify responsibilities and refactor classes to adhere to SRP, ensuring that code remains clean and manageable.
How does Clean Code address error handling?
- Use Exceptions: The book advocates for using exceptions rather than return codes for error handling, which helps keep the main logic of the code clean and unobscured.
- Separation of Concerns: Error handling should be separated from the main logic of the code, allowing developers to focus on the primary functionality without being bogged down by error-checking clutter.
- Provide Context: Exceptions should provide enough context to understand the source and nature of the error, making it easier to diagnose and fix issues when they arise.
What role does testing play in Clean Code?
- Foundation of Clean Code: Testing is considered a fundamental discipline in writing clean code. It ensures that the code behaves as expected and helps catch issues early in the development process.
- Fast and Reliable Tests: The book emphasizes that tests should be fast and reliable to encourage frequent execution. This helps maintain a clean codebase and reduces the risk of introducing bugs.
- Self-Validating Tests: Tests should be designed to be self-validating, meaning they should clearly indicate whether the code is functioning correctly. This reduces ambiguity and increases confidence in the code.
How does Clean Code suggest handling dependencies?
- Dependency Inversion Principle (DIP): The book explains that "high-level modules should not depend on low-level modules. Both should depend on abstractions." This principle encourages the use of interfaces and abstract classes to reduce coupling.
- Use of Dependency Injection: Martin recommends using dependency injection to manage dependencies, allowing for more flexible and testable code. This approach decouples the creation of dependencies from their usage.
- Benefits of Managing Dependencies: By managing dependencies effectively, developers can create systems that are easier to maintain and extend, leading to cleaner and more robust code.
What are some common code smells identified in Clean Code?
- Duplicated Code: This is a major code smell that indicates a lack of abstraction. The book advises eliminating duplication to improve maintainability and reduce errors.
- Long Methods: Methods that are too long can be difficult to understand and maintain. The book suggests breaking them down into smaller, more manageable functions.
- Excessive Comments: While comments can be helpful, excessive or redundant comments often indicate that the code itself is not clear. The goal should be to write self-explanatory code that requires minimal comments.
How can I apply the principles from Clean Code in my own projects?
- Start with Small Changes: Begin by applying the principles of clean code to small sections of your codebase. Refactor one class or function at a time to improve readability and maintainability.
- Write Tests First: Adopt Test-Driven Development (TDD) practices by writing tests before implementing new features. This ensures that your code is always covered by tests and helps maintain quality.
- Regularly Refactor: Make refactoring a regular part of your development process. Continuously look for opportunities to improve code structure and eliminate duplication, keeping your codebase clean and efficient.
Отзывы
Чистый код считается обязательным чтением для разработчиков программного обеспечения, предоставляя ценные идеи о том, как писать читаемый и поддерживаемый код. Хотя книга получила похвалу за практические советы по соглашениям об именах, проектированию функций и тестированию, некоторые читатели сочли её слишком ориентированной на Java и иногда чрезмерной в своих рекомендациях. Кейс-стадии книги вызвали смешанные реакции: некоторые нашли их полезными, а другие остались менее впечатлёнными. Несмотря на свои недостатки, многие разработчики считают её обязательной к прочтению, так как она значительно улучшила их практики кодирования и понимание мастерства программного обеспечения.
Similar Books
