Which door represents your code? Which door represents your team or your company?
Why are we in that room? Is this just a normal code review or have we found a stream of
horrible problems shortly after going live? Are we debugging in a panic, poring over code
that we thought worked? Are customers leaving in droves and managers breathing down
our necks? How can we make sure we wind up behind the right door when the going gets
tough? The answer is: craftsmanship.
There are two parts to learning craftsmanship: knowledge and work. You must gain
the knowledge of principles, patterns, practices, and heuristics that a craftsman knows, and
you must also grind that knowledge into your fingers, eyes, and gut by working hard and
practicing.
I can teach you the physics of riding a bicycle. Indeed, the classical mathematics is
relatively straightforward. Gravity, friction, angular momentum, center of mass, and so
forth, can be demonstrated with less than a page full of equations. Given those formulae I
could prove to you that bicycle riding is practical and give you all the knowledge you
needed to make it work. And you’d still fall down the first time you climbed on that bike.
Coding is no different. We could write down all the “feel good” principles of clean
code and then trust you to do the work (in other words, let you fall down when you get on
the bike), but then what kind of teachers would that make us, and what kind of student
would that make you?
No. That’s not the way this book is going to work.
Learning to write clean code is hard work. It requires more than just the knowledge of
principles and patterns. You must sweat over it. You must practice it yourself, and watch
yourself fail. You must watch others practice it and fail. You must see them stumble and
retrace their steps. You must see them agonize over decisions and see the price they pay for
making those decisions the wrong way.
Be prepared to work hard while reading this book. This is not a “feel good” book that
you can read on an airplane and finish before you land. This book will make you work, and
work hard. What kind of work will you be doing? You’ll be reading code—lots of code.
And you will be challenged to think about what’s right about that code and what’s wrong
with it. You’ll be asked to follow along as we take modules apart and put them back
together again. This will take time and effort; but we think it will be worth it.
We have divided this book into three parts. The first several chapters describe the principles,
patterns, and practices of writing clean code. There is quite a bit of code in these
chapters, and they will be challenging to read. They’ll prepare you for the second section
to come. If you put the book down after reading the first section, good luck to you!
The second part of the book is the harder work. It consists of several case studies of
ever-increasing complexity. Each case study is an exercise in cleaning up some code—of
transforming code that has some problems into code that has fewer problems. The detail in
this section is intense. You will have to flip back and forth between the narrative and the
code listings. You will have to analyze and understand the code we are working with and
walk through our reasoning for making each change we make. Set aside some time
because this should take you days.
The third part of this book is the payoff. It is a single chapter containing a list of heuristics
and smells gathered while creating the case studies. As we walked through and
cleaned up the code in the case studies, we documented every reason for our actions as a
Introduction
heuristic or smell. We tried to understand our own reactions to the code we were reading
and changing, and worked hard to capture why we felt what we felt and did what we did.
The result is a knowledge base that desribes the way we think when we write, read, and
clean code.
This knowledge base is of limited value if you don’t do the work of carefully reading
through the case studies in the second part of this book. In those case studies we have carefully
annotated each change we made with forward references to the heuristics. These forward
references appear in square brackets like this: [H22]. This lets you see the context in
which those heuristics were applied and written! It is not the heuristics themselves that are
so valuable, it is the relationship between those heuristics and the discrete decisions we
made while cleaning up the code in the case studies.
To further help you with those relationships, we have placed a cross-reference at the end
of the book that shows the page number for every forward reference. You can use it to look
up each place where a certain heuristic was applied.
If you read the first and third sections and skip over the case studies, then you will
have read yet another “feel good” book about writing good software. But if you take the
time to work through the case studies, following every tiny step, every minute decision—if
you put yourself in our place, and force yourself to think along the same paths that we
thought, then you will gain a much richer understanding of those principles, patterns, practices,
and heuristics. They won’t be “feel good” knowledge any more. They’ll have been
ground into your gut, fingers, and heart. They’ll have become part of you in the same way
that a bicycle becomes an extension of your will when you have mastered how to ride it.
Acknowledgments
Thank you to my two artists, Jeniffer Kohnke and Angela Brooks. Jennifer is responsible
for the stunning and creative pictures at the start of each chapter and also for the portraits
of Kent Beck, Ward Cunningham, Bjarne Stroustrup, Ron Jeffries, Grady Booch, Dave
Thomas, Michael Feathers, and myself.
Angela is responsible for the clever pictures that adorn the innards of each chapter.
She has done quite a few pictures for me over the years, including many of the inside pictures
in Agile Software Develpment: Principles, Patterns, and Practices. She is also my
firstborn in whom I am well pleased.
A special thanks goes out to my reviewers Bob Bogetti, George Bullock, Jeffrey
Overbey, and especially Matt Heusser. They were brutal. They were cruel. They were
relentless. They pushed me hard to make necessary improvements.
Thanks to my publisher, Chris Guzikowski, for his support, encouragement, and jovial
countenance. Thanks also to the editorial staff at Pearson, including Raina Chrobak for
keeping me honest and punctual.
Thanks to Micah Martin, and all the guys at 8th Light (www.8thlight.com) for their
reviews and encouragement.
Thanks to all the Object Mentors, past, present, and future, including: Bob Koss,
Michael Feathers, Michael Hill, Erik Meade, Jeff Langr, Pascal Roy, David Farber, Brett
Schuchert, Dean Wampler, Tim Ottinger, Dave Thomas, James Grenning, Brian Button,
Ron Jeffries, Lowell Lindstrom, Angelique Martin, Cindy Sprague, Libby Ottinger, Joleen
Craig, Janice Brown, Susan Rosso, et al.
Thanks to Jim Newkirk, my friend and business partner, who taught me more than
I think he realizes. Thanks to Kent Beck, Martin Fowler, Ward Cunningham, Bjarne
Stroustrup, Grady Booch, and all my other mentors, compatriots, and foils. Thanks to John
Vlissides for being there when it counted. Thanks to the guys at Zebra for allowing me to
rant on about how long a function should be.
And, finally, thank you for reading these thank yous.
On the Cover
The image on the cover is M104: The Sombrero Galaxy. M104 is located in Virgo and is
just under 30 million light-years from us. At it’s core is a supermassive black hole weighing
in at about a billion solar masses.
Does the image remind you of the explosion of the Klingon power moon Praxis? I
vividly remember the scene in Star Trek VI that showed an equatorial ring of debris flying
away from that explosion. Since that scene, the equatorial ring has been a common artifact
in sci-fi movie explosions. It was even added to the explosion of Alderaan in later editions
of the first Star Wars movie.
What caused this ring to form around M104? Why does it have such a huge central
bulge and such a bright and tiny nucleus? It looks to me as though the central black hole
lost its cool and blew a 30,000 light-year hole in the middle of the galaxy. Woe befell any
civilizations that might have been in the path of that cosmic disruption.
Supermassive black holes swallow whole stars for lunch, converting a sizeable fraction
of their mass to energy. E = MC2 is leverage enough, but when M is a stellar mass:
Look out! How many stars fell headlong into that maw before the monster was satiated?
Could the size of the central void be a hint?
The image of M104 on the cover is a
combination of the famous visible light photograph
from Hubble (right), and the recent
infrared image from the Spitzer orbiting
observatory (below, right). It’s the infrared
image that clearly shows us the ring nature
of the galaxy. In visible light we only see the
front edge of the ring in silhouette. The central
bulge obscures the rest of the ring.
But in the infrared, the hot particles in
the ring shine through the central bulge. The
two images combined give us a view we’ve
not seen before and imply that long ago it
was a raging inferno of activity.
