The fifth practice from my book Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software, is called Create CLEAN Code.
CLEAN is an acronym but it’s also a shout out to the books Clean Code and The Clean Coder by Robert C. Martin. and to the Clean Code talks, a series of Google Tech Talks, by Misko Hevery. Both of these resources hold outstanding value for software developers.
I’ve overloaded the term here myself to mean five specific things that we can look at in code to determine it’s understandability.
These five code qualities are actually quantifiable, we can see them in code and as we improve them our software becomes more straightforward to maintain and extend.
These same qualities go far beyond the realm of software development because they’re really reflections on the way we think and understand the world. The way we form concepts and communicate also has these qualities. They show up in the design of everyday things and how we organize our lives because they are indeed fundamental to the way we think and understand.
Interested to know more about these qualities? I take a deep dive into them in my book and also in several posts on my blog so I encourage you to check out some of my other posts on code qualities. Here I’ll just describe them briefly:
The C in CLEAN stands for cohesive. This means that a software entity, either a class or a method, for example, is about one thing and at a single level of abstraction. This is important because we want to make the behavior of our systems something that we can easily name and so behaviors must be well represented by the names that we give them.
L stands for loosely coupled, which means that when code has dependencies on external services then we want to connect to them indirectly. We want to create code that’s decoupled from its dependencies so that we can independently test and verify it.
E stands for encapsulated, which means that we hide internal implementation details and only present a defined interface to the outside world. Encapsulated code is more modular and has far fewer side effects.
A stands for assertive which means that in the object-oriented model all objects are in charge of themselves and of managing their state. This makes it more straightforward for objects to interact in the system and be far less entangled when systems are extended.
N stands for nonredundant which means that we do things only once. Redundancy can have subtle forms which look different but actually do the same thing and we want to rid our systems of those subtle forms of redundancy so that the design becomes clearer and the code becomes cleaner.
Each one of these code qualities affects the other. When one is poor then others tend to be poor as well. When we improve one it also tends to improve the others.
This means that you don’t have to focus on all of them, just pick one or two that make the most sense to you and focus on them. As you improve one of them you’ll notice that others improve as well and that’s because these code qualities are actually facets of the same thing–the same gem–which is the code. They are different lenses by which we see our code or evaluate our code and good code tends to have all of these qualities.
Having discussed each of these code qualities in detail in previous blog posts, which you can easily find on my website, I will now dive deeper over the next seven blog posts, into strategies for increasing code quality, which comes from my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software, in a section called Seven Strategies for Increasing Code Quality.
Previous Post: « Track Progress
Next Post: Get Crisp on the Definition of Quality »