Clean Code Tip 6: Write code that is easy to change
Evolution is a fundamental principle of nature, and it is equally applicable to software. Software systems inevitably require modification over time, which may span months, years, or even decades. Consequently, code should be structured to facilitate ease of modification. However, effective modification is only possible when the code's functionality is clearly understood. Achieving this understanding depends on the code being both readable and comprehensible. Readability and clarity are essential prerequisites for successful code modification.
When your code is messy, it takes longer to understand and change it. You might run into unexpected issues, need to refactor, or deal with technical debt, all of which slow you down. Messy code is also riskier to change than clean code. Even if you think you understand it, you could make a mistake and introduce a bug. If time is money, then messy code costs you because it slows down your work. If your software is slow to change, customers may choose another company that can deliver faster. The same goes for bugs—customers prefer companies that write clean code with fewer problems. When your code is clean, making a change usually means reading less code, which leads to the need to understand less code, and the code that you must read and understand is usually very readable and understandable, all of which contribute to the fact that changing clean code is both faster and less risky than changing messy code.
When you need to update your code, it's much easier if you only have to make the change in one spot. If your code has duplicates, you might have to update the same thing in several places, which can easily lead to mistakes. I've seen this happen often when working with older code.
The most maintainable code is code that does not require modification. Achieving this is possible by favoring extension over modification, a concept that will be explored further in the next section when discussing the open-closed principle (OCP). Extending code is generally safer than altering existing code, as modifications can introduce errors into previously functional components. Even with a thorough understanding of the codebase, small mistakes may occur during modification. By extending rather than changing code, the risk of disrupting existing functionality is minimized. Extension can be accomplished by providing a new implementation, such as a class for an abstraction (for example, an interface), or by extending an existing class. These new classes are then integrated into the application, which can be achieved through various methods, including the use of a factory.
Two principles significantly facilitate code modification:
Don't repeat yourself (DRY)
Cohesion: Group related data and behavior together
The DRY principle ensures that specific knowledge or logic exists in only one location within the code base, which simplifies modifications. Cohesion involves co-locating related data and behavior, typically through object-oriented design by defining classes. For instance, a class named User should encapsulate all user-related data and behavior. Similarly, a class named ConfigReader should contain all data and behavior associated with configuration reading in a single location.
In addition to the time-to-understand metric, another essential indicator of clean code is the change lead time, defined as the duration between identifying a required change and deploying it to production. Change lead time is complemented by several related metrics, including code churn, change diffuseness, and defect introduction rate after changes. Code churn quantifies the magnitude and volatility of modifications necessary to implement a change, such as the number of lines altered. Change diffuseness assesses the extent to which a single change request necessitates modifications across multiple files, classes, or modules. Clean code facilitates localized (low change diffuseness) and minimal (low code churn) changes, which are associated with significantly reduced defect rates. The low incidence of defects following changes is often attributed to the open-closed principle, which prohibits altering existing, functional code. In contrast, unclean code bases are more susceptible to introducing errors during bug fixes or feature additions, as these changes are more likely to disrupt existing functionality.
If you are interested in reading more about clean code, grab yourself a copy of my 140 Tips For Clean Code booklet.
