Clean Code

 Conclusion
It is not enough for code to work. Code that works is often badly broken. Programmers
who satisfy themselves with merely working code are behaving unprofessionally. They
may fear that they don’t have time to improve the structure and design of their code, but I
disagree. Nothing has a more profound and long-term degrading effect upon a develop-
ment project than bad code. Bad schedules can be redone, bad requirements can be rede-
fined. Bad team dynamics can be repaired. But bad code rots and ferments, becoming an
inexorable weight that drags the team down. Time and time again I have seen teams grind
to a crawl because, in their haste, they created a malignant morass of code that forever
thereafter dominated their destiny.
Of course bad code can be cleaned up. But it’s very expensive. As code rots, the mod-
ules insinuate themselves into each other, creating lots of hidden and tangled dependen-
cies. Finding and breaking old dependencies is a long and arduous task. On the other hand,
keeping code clean is relatively easy. If you made a mess in a module in the morning, it is
easy to clean it up in the afternoon. Better yet, if you made a mess five minutes ago, it’s
very easy to clean it up right now.
So the solution is to continuously keep your code as clean and simple as it can be.
Never let the rot get started.

---

251
15
JUnit Internals
JUnit is one of the most famous of all Java frameworks. As frameworks go, it is simple in
conception, precise in definition, and elegant in implementation. But what does the code
look like? In this chapter we’ll critique an example drawn from the JUnit framework. 

---

252
Chapter 15: JUnit Internals
The JUnit Framework
JUnit has had many authors, but it began with Kent Beck and Eric Gamma together on a
plane to Atlanta. Kent wanted to learn Java, and Eric wanted to learn about Kent’s Small-
talk testing framework. “What could be more natural to a couple of geeks in cramped
quarters than to pull out our laptops and start coding?”
1
After three hours of high-altitude
work, they had written the basics of JUnit.
The module we’ll look at is the clever bit of code that helps identify string compari-
son errors. This module is called 
ComparisonCompactor
. Given two strings that differ,
such as 
ABCDE
and
ABXDE,
it will expose the difference by generating a string such as
<...B[X]D...>
.
I could explain it further, but the test cases do a better job. So take a look at Listing 15-1
and you will understand the requirements of this module in depth. While you are at it,
critique the structure of the tests. Could they be simpler or more obvious?
1.
JUnit Pocket Guide
, Kent Beck, O’Reilly, 2004, p. 43.