CLEAN stands for five key code qualities that improve software’s maintainability. They are cohesive, loosely coupled, encapsulated, assertive, and non-redundant. These five code qualities make software more straightforward to work with.
Summary of Seven Strategies Series
I finished my “Seven Strategies” series of 72 blog posts with seven strategies for implementing each of the nine practices from my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software. These posts are filled with practical advice for implementing the nine core practices from Scrum, Extreme Programming, and …
Continue reading “Summary of Seven Strategies Series”
Read MoreKeep Code Testable
I’d like to wrap up these Seven Strategies for Increasing Code Quality with a strategy that kinda sums up all the rest of them—keep code testable. Untested software carries a great deal of risk. If a developer who implements a feature test it manually only once then that feature may be affected by other changes …
Continue reading “Keep Code Testable”
Read MoreName Things Well
Shakespeare said, “a rose by any other name…” To him, a name was just a label for something deeply intrinsic within the thing itself. But in software, it’s the opposite. There is no intrinsic-ness to any software objects except what they do and so our names become more than labels, they become expressions of the …
Continue reading “Name Things Well”
Read MoreHide How with What
As I was writing my book, Beyond Legacy Code, I started to see a pattern emerge. Practice 1 is “say what, why, and for whom before how.” One of the anti-patterns in software development, and therefore something that we want to avoid, is leaking implementation details in our code by saying how we do something …
Continue reading “Hide How with What”
Read MoreUnderstand Trade-Offs
When we talk about code qualities and code quality practices we may have a tendency to believe that more is better, universally but that’s not always the case. We want software to run fast but we also want it to be easy to understand when we go to change it. Sometimes these characteristics and qualities …
Continue reading “Understand Trade-Offs”
Read MoreLet Go of Perfectionism
It was Voltaire who said, “Don’t let the perfect be the enemy of the good.” By that what I believe he meant was that while it might be good to strive for perfection we have to realize that we won’t always achieve it and if we are going to insist on everything being perfect we …
Continue reading “Let Go of Perfectionism”
Read MoreShare Common Quality Practices
In addition to sharing a common definition of what quality means in terms of CLEAN code, we also must share some common quality practices that can help us increase the quality of the code we create. These practices should be straightforward to apply so we can easily make them our habits. Here are some of …
Continue reading “Share Common Quality Practices”
Read MoreGet Crisp on the Definition of Quality
When we talk about quality we may think of a fine piece of furniture or the quality service we receive at a fancy restaurant but what does quality mean in the context of software? I find that when we talk about the domain of ideas, and software is in the domain of ideas, that we …
Continue reading “Get Crisp on the Definition of Quality”
Read MoreWhy Practice 5: Create CLEAN Code
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 …
Continue reading “Why Practice 5: Create CLEAN Code”
Read MoreEncapsulate Change
Software development is a unique human activity but it bears resemblance to other activities such as math, writing, and engineering. I think of writing software as a modeling process but unlike modeling physical things that occur in space, we’re modeling processes that occur in time. Therefore, writing software is a process of creating models that …
Continue reading “Encapsulate Change”
Read MoreName Things Well
I’ve said that the five code qualities we’ve been discussing are quantifiable. That is, we can create more of them if we want. Let’s discuss how to do this. The one code quality I’d like to focus on is cohesion. To me, it makes the most sense and I can easily see when my code …
Continue reading “Name Things Well”
Read MoreTestability Affects Code Quality
Why is it that if we all agree that CLEAN code is good to strive for that the vast majority of software as written lacks these qualities? The only answer I can come up with is that we’re so focused on short-term gains that we forget about the long-term consequences. I have to point out …
Continue reading “Testability Affects Code Quality”
Read MoreLet Code Quality Guide You
Back in the 1990s, when I was faced with multiple design choices, I’d have to code them up in multiple ways to figure out which one was best. This was time-consuming, and evaluating design choices was one of the hardest things for me. But now I have a better approach, thanks to code qualities. If …
Continue reading “Let Code Quality Guide You”
Read MoreNonredundancy and Testability
Redundancy is always a maintenance issue. If you have to change redundant code, you have to do it in multiple places. If you have to extend redundant code, you have to do it in multiple places. When you have to test redundant code, you have to modify tests in multiple places. You get the idea. …
Continue reading “Nonredundancy and Testability”
Read MorePathologies of Redundant Code
Remember Y2K? Before the turn of the millennium, computer storage was at such a premium that years were stored with only the last two digits so the year 1989 was stored as 89. This worked fine—up until the end of 1999, at which point the year returns to 00 which many programs would interpret as …
Continue reading “Pathologies of Redundant Code”
Read MoreQuality Code is Nonredundant
The last code quality that we’ll discuss in this series, the “N” in CLEAN, calls for code to be nonredundant. On its surface it seems pretty straightforward but there is some subtlety to redundancy as well. It’s easy to see why redundancy in code is a bad thing. It’s a duplicated effort. It means that …
Continue reading “Quality Code is Nonredundant”
Read MoreAssertiveness and Testability
It’s quite difficult to test inquisitive code. Very often the results of running a piece of code can only be found in another object. Therefore a test must use a separate entity, which we typically call a “spy,” to monitor the external object and validate that it was called correctly. This adds unnecessary complexity to …
Continue reading “Assertiveness and Testability”
Read MorePathologies of Inquisitive Code
Objects that are not assertive are by default inquisitive. They are either inquisitive or they are mute. They don’t interact with the outside word at all. If an object interacts with other objects, the real question with regard to assertiveness is, “Who’s in charge?” One object can delegate a task to another object but still …
Continue reading “Pathologies of Inquisitive Code”
Read MoreQuality Code is Assertive
The next code quality in this series of posts, the “A” in CLEAN, stands for assertive. I don’t hear a lot of people talking about it but I think it’s an important code quality. We want the software we write to be assertive, to be in charge of its own state. We want objects to …
Continue reading “Quality Code is Assertive”
Read MoreEncapsulation and Testability
Poorly encapsulated software is hard to test because without clear boundaries, what we actually test becomes significantly larger than what we need to test. This makes our tests run slower and it also makes them brittle so our tests are harder to maintain. When code is unencapsulated, it can be hard to lock down behaviors …
Continue reading “Encapsulation and Testability”
Read MorePathologies of Unencapsulated Code
Unencapsulated code is code that exposes its implementation or references how it does something. This can happen in subtle ways, so we have to be careful to create strong contracts through our method signatures. Poorly encapsulated code is very difficult to work with. It can quickly sprout new bugs at the slightest change. Lack of …
Continue reading “Pathologies of Unencapsulated Code”
Read MoreQuality Code is Encapsulated
To encapsulate something is to envelope and protect it. Encapsulation is a fundamental facility that every programming language supports at some level. Encapsulation is about hiding implementation details so ideas can be expressed at higher levels and to protect those details from other parts of the system. To me, most fundamentally, encapsulation means hiding implementation …
Continue reading “Quality Code is Encapsulated”
Read More