Catalog / Clean Code Principles & Practices
Clean Code Principles & Practices
A cheat sheet summarizing key principles and practices for writing clean, maintainable, and readable code.
Core Principles
Readability & Simplicity
Principle: Code should be easy to understand and modify.
|
Benefit: Reduces cognitive load, speeds up debugging, and facilitates collaboration. |
Example:
|
DRY (Don't Repeat Yourself)
Principle: Avoid duplicating code. Abstract common logic into reusable functions or modules. |
Benefit: Reduces redundancy, simplifies maintenance, and minimizes the risk of inconsistencies. |
Example:
|
KISS (Keep It Simple, Stupid)
Principle: Favor simplicity over complexity. Choose the simplest solution that meets the requirements. |
Benefit: Easier to understand, debug, and maintain. Reduces the likelihood of introducing bugs. |
Example:
|
Functions
Function Length
Guideline: Functions should be small and focused. Ideally, a function should not exceed 20-30 lines of code. |
Reasoning: Shorter functions are easier to understand, test, and reuse. They promote modularity and reduce complexity. |
Technique: Break down large functions into smaller, more manageable sub-functions. |
Example:
|
Function Arguments
Guideline: Minimize the number of function arguments. Ideally, a function should have 0-3 arguments. |
Reasoning: Functions with fewer arguments are easier to call and understand. They reduce the risk of errors and improve readability. |
Technique: Use objects or data structures to group related arguments. Consider using a builder pattern for functions with many optional arguments. |
Example:
|
Function Naming
Guideline: Choose descriptive and meaningful names for functions. Function names should clearly indicate what the function does. |
Reasoning: Good function names improve code readability and make it easier to understand the purpose of the function. |
Technique: Use verbs to name functions (e.g., |
Example:
|
Comments and Documentation
Purpose of Comments
Guideline: Comments should explain the why behind the code, not the what. Good code should be self-documenting. |
Reasoning: Comments can provide valuable context and insights into the design decisions and intent of the code. |
Technique: Use comments sparingly and only when necessary to clarify complex logic or provide additional information. |
Best Practice: Avoid redundant comments that simply restate the code. |
Documentation
Guideline: Use documentation to describe the purpose, usage, and design of modules, classes, and functions. |
Reasoning: Documentation helps other developers (and your future self) understand how to use and maintain the code. |
Technique: Use docstrings, README files, and other forms of documentation to provide comprehensive information about the codebase. |
Tools: Sphinx (Python), JSDoc (JavaScript), etc. |
Commenting Style
Guideline: Follow a consistent commenting style throughout the codebase. |
Reasoning: Consistent style improves readability and maintainability. |
Technique: Use appropriate commenting syntax for the programming language (e.g., |
Example:
|
Error Handling
Importance of Error Handling
Guideline: Implement robust error handling to prevent unexpected crashes and provide informative error messages. |
Reasoning: Proper error handling improves the reliability and usability of the software. |
Technique: Use try-except blocks (or equivalent) to catch exceptions and handle them gracefully. |
Best Practice: Log errors for debugging and monitoring purposes. |
Specific Exceptions
Guideline: Catch specific exceptions rather than general exceptions. |
Reasoning: Catching specific exceptions allows you to handle different types of errors in different ways. |
Technique: Identify the specific exceptions that can be raised by the code and catch them individually. |
Example:
|
Resource Management
Guideline: Ensure that resources (e.g., files, network connections) are properly released after use. |
Reasoning: Failure to release resources can lead to resource leaks and performance issues. |
Technique: Use try-finally blocks or context managers (e.g., |
Example:
|