Chapter 1

What This Book Is About

Good programming practices/techniques
What is good and bad code
How to write good code
Refactoring

There Will Be Bad Code

Code represents the details of the requirements, the specifications
Code is the language in which we ultimately express the requirements
We will never completely eliminate the need for precision in our code

Bade Code

Good code matters, and this is often overlook by industry professionals
Example of 'killer app' which very quickly became a disaster as updates continued in a messy repository. The bad code brought the company down
Question: "Have you ever been significantly impeded by bad code, and if so why/how?"
Often code is rushed in a poor state due to external stresses: Tired of working on the program, meeting a deadline or working in large teams
It becomes increasingly difficult to clean up your code the more your pile on top of the bad code

Total Cost of Owning a Mess

As teams progress, you will often find making one change will break 2-3 other things along the way
Every change becomes non-trivial
May get to the stage where it is near impossible to make incremental positive changes

The Grand Redesign in the Sky

Eventually the problem gets so bad the employees want to do something about it
A new team is allocated to start over, alongside the original team who must maintain the current system
New team must build the new system and incorporate and changes made by the original team, as the original team won't be replaced until the new system is completely built
This can take many, many years and will see the 'new' system face the exact same problems and the original system did

Attitude

Whilst we can blame everything and everyone, it ultimately comes down to us as developers
Managers/non-technical employees will look to you to make informed decisions about deadlines
Most managers want the truth, even when they don't act like it
Most managers want good code, irrespective of what they say about the schedule
It's YOUR job to defend both the code, and your opinions. You will become opinionated

The Primal Conundrum

Previous messes slow you down. Yet all developers feel pressure to make mess to meet deadlines
True professionals know that the second part of this is wrong, you will not make the deadline by making a mess
The only way to go 'fast' is to keep the code as clean as possible at all times

The Art of Clean Code?

Writing clean code is like painting a picture, you know when it is painted well or badly
However, being able to recognise good and bad art, does not mean you know how to paint
Writing clean code requires many little techniques applied together
A programmer with 'code sense' has the ability to look through a messy module and see options and variations

What is Clean Code?

Bjarne Stroustrup

"I like my code to be elegant and efficient. The logic should be straightforward to make it hard for bugs to hide, the dependencies minimal to ease maintenance, error handling complete according to an articulated strategy, and performance close to optimal so as not to tempt people to make the code messy with unprincipled optimisations. Clean code does one thing well."

Bjarne mentions code should be elegant and pleasing.
Efficiency is also highlighted
Bad code tempts the mess to grow, and tempts developers to make changes they shouldn't
Bad code tries to do too much, it should do one thing well

Grady Booch

"Clean code is simple and direct. Clean code reads like well-written prose. Clean code never obscures the designer's intent but rather is full of crisp abstractions and straightforward lines of control."

Takes more of a readability perspective
Our code should be matter-of-fact as opposed to speculative
Can easily tell what is going on

Dave Thomas

Clean code can be read, and enhanced by a developer other than its original author. It has unit and acceptance tests. It has meaningful names. It provides one way rather than many ways for doing one thing. It has minimal dependencies, which are explicity defined, and provides a clear and minimal API. Code should be literate since depending on the language, not all necessary information can be expressed clearly in code alone.
Clean code makes it easy for other people to enhance it
Often you will inherit or pass on code
Cleanliness is tied to tests, code without tests is not clean
Tests act as the specifications of your code
Smaller is better when code is literate

Michael Feathers

"I could list all of the qualities that I notice in clean code, but there is one overarching quality that leads to all of them. Clean code always looks like it was written by someone who cares. There is nothing obvious that you can do to make it better. All of those things were thought about by the code's author, and if you try to image improvements, you're led back to where you are, sitting in appreciation of the code someone left for you - code left by someone who cares deeply about the craft."

Care is the main highlight
Clean code is code that has been taken care of, it's as simple as that

Ron Jeffries

"In recent years I begin, and nearly end, with Beck's rules of simple code. In priority order, simple code:

Runs all tests
Contains no duplications
Expresses all the design ideas that are in the system
Minimises the number of entities such as classes/methods/functions.

Of these, I focus mostly on duplications. When the same thing is done over and over, it's a sign that there is an idea in our mind that is not well represented in the code. I try to figure out what it is. Then I try to express that idea more clearly. Expressiveness to me includes meaningful names, and I am likely to change the names of things several times before I settle in. With modern coding tools such as Eclipse, renaming is quite inexpensive, so it doesn't trouble me to change.

Expressiveness goes beyond names, however. I also look at whether an object or method is doing more than one thing. If it's an object, it probably needs to be broken into two or more objects. If it's a method, I will always use the Extract Method refactoring on it, resulting in one method that says more clearly what it does, and some sub-methods saying how its done.

Duplication and expressiveness take me a very long way into what I consider clean code, and improving dirty code with just these two things in mind can make a huge difference. There is, however, one thing that I'm aware of doing, which is a bit harder to explain.

After years of doing this work, it seems to me that all programs are made up of very similar elements. One example is 'find things in a collection'. Whether we have a database of employee records, or a hash map of keys and values, or an array of items of some kind, we often find ourselves wanting a particular item from that collection. When I find that happening, I will often wrap the particular implementation in a more abstract method or class. That gives me a couple of interesting advantages.

I can implement the functionality now with something simple, say a hash map, but since now all the references to that search are covered by my little abstraction, I can change the implementation any time I want. I can go forward quickly while preserving my ability to change later.

In addition, the collection abstraction often calls my attention to what's 'really' going on, and keeps me from running down the path of implementing arbitrary collection behaviour when all I really need is a few fairly simple ways of finding what I want.

Reduced duplications, high expressiveness, and early building of simple abstractions. That's what makes clean code for me."

Ward Cunningham

"You know you are working on clean code when each routine you read turns out to be pretty much what you expected. You can call it beautiful code when the code also makes it look like the language was made for the problem."

"Pretty much what you expected". This about sums it up
Programs which are clean, as so well written that you don't even notice it
Beautiful code makes the language look like it was made for the problem

Schools of Thought

Many of the recommendations in this book are controversial, and you may not agree with all of them
However, they have been thought about long and hard but experienced professionals
It is also important to note, other 'masters/teachers' out there will have different opinions which conflict with our own, neither us nor they are necessarily incorrect

We are Authors

We are authors, and authors have readers
Authors are responsible for communicating well with their reads
The ratio of time spent reading versus writing code is well over 10:1
We want the reading of code to be easy, even if it makes the writing harder

The Boy Scout Rule

Code has to be kept clean over time
The Boy Scouts of America have a simple rule: "Leave the camp ground cleaner than you found it."
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, break up a function, eliminate one small bit of duplication etc

Conclusion

This book cannot promise to make you a good programmer
It can show you the though processes of good programmers and the tricks, techniques and tools they use
Practice is the only way to progress