I'm not afraid to admit it - I've been doing it all wrong.
I thought that I had been writing some decent code. I've just
finished reading
Clean Code and it turns out that I haven't. As it happens I've
been writing some terrible code.
I was recommended
this book by Paul
Stack (@stack72). So I
popped down to the nearest Waterstones (other stores available) and
picked up the last copy. Trudging back to work, I skimmed the back
page and have to admit I thought it would be a bit of a dull
read.
How wrong could I be?! After the first chapter I was hooked, I
read the whole book - yesterday. Yes one day! I
couldn't put it down.
The thing that strikes me as odd is that not one person I have
worked with has ever mentioned this book. Which means they are
probably doing it wrong too. This book is an absolute must! I wish
I could go back in time and make this the first development book I
ever read. Unfortunately, I'm pretty sure we haven't quite mastered
time travel just yet. So I will have to make do with looking at all
the code I have written and quietly sobbing.
Don't get me wrong, the code I've been writing is probably not
that bad and after all it does actually work. But that is the
point - that's all it does, it works. You can tell by looking
at it that once it was finished and working I left it. I left it to
move on to other things, to work on other code that had deadlines
looming.
Reading Clean Code has made me realise that 99% of any comments
that I have ever written in code are worthless. Complete nonsense
that need not be there. If I had taken the time and care to really
look at what I was writing then I wouldn't have needed to put a
comment.
Time and care. These are words that are not normally associated
with coding. Most of us don't have or don't believe we have, the
time to spend refactoring code. But this book has convinced me to
make time. This is my work, my profession. Why am I not caring
about my code? If a carpenter didn't care about their work then
they would produce shoddy products. Sure they would probably work
but they wouldn't look pretty or have a nice finish.
Clean Code highlights lots of different scenarios that should be
setting off alarms bells. The bells are ringing and they are
ringing loudly.
Simple things like only allowing functions to do one thing. I
haven't been doing and the code gets messy. It's a quick and easy
fix to add a little piece of code in to a function. Job done. Bug
resolved. But alas, you have just planted the seed to something
that if left alone will destroy your whole code base!
The ideas and recommendations that this book provides are not
difficult - they may be difficult to master but to implement they
are simple. If you see a piece of code that could potentially be
modified to make it easier to read or to be re-used then do it.
Don't hold back - potentially fixing something counts for nothing
if you aren't actually going to fix it. We are
also afraid to use the delete key - preferring to comment out
huge swathes of code. Just delete it. Source control will remember
it - you don't have to.
I can't explain how much this book had changed my view of
writing, refactoring and taking care of my code. From now on, every
estimate for any development will allow for time to refactor and
properly test the code I am creating and/or extending. It
seems absurd that I haven't been following the practices in this
book from the outset.
For me this book is a massive game changer, it's made me realise
that you won't always write perfect code and you certainly won't
write perfect code the first time. It can always be improved. Your
codebase is always growing, evolving, and what seemed to be a
perfect function or class a few months/weeks/days ago no longer
applies. Changes have been made and refactoring can be done.
It's also opened my eyes that getting other people to review and
modifiy your code isn't a bad thing. It's not a personal slur on
you - it's just that they will see things differently. They will
pick up on mistakes, or should that be improvements, that you will
miss.
From now on, I will be trying to craft my code like stories. And
that is exactly what it is - a craft. Piecing things together,
rearranging, amalgamating and splitting code until it describes
exactly what you are trying to achieve. No more comments - the code
should speak for itself. The reader should enjoy the experience of
opening your source files, not recoil back in horror.
To quote a paragraph from the book:
"If we all checked-in our code a little cleaner than
when we checked it out, the code simply could not rot. The cleanup
doesn't have to be something big. Change one variable name for the
better, break up one function that's a little too large, eliminate
one small bit of duplicationm clean up one composite 'if'
statement"
This isn't about refactoring 1000's of lines of code in one go -
it's about making those little changes that we always (or should
always) notice but never actually modify.
This book has inspired me, I am planning to refactor and add
proper tests to my FilterMe
plugin for Seesmic and then hopefully make it open source.
Previously, I wouldn't have dreamt of doing this, of putting my
code out there on the internet for anyone to review. I have changed
though. I am looking forward to correcting my previous mistakes,
allowing other developers (potentially people I have never met) to
review my code. I want them to highlight the errors, to pose the
question "Why have you done x like that? Why not do it like
this?"
Now if you'll excuse me I'm off to refactor some code, one
variable name at a time.
Next up on the book list .... The Art of Unit Testing