Clean Code: A Handbook of Agile Software Craftsmanship and over one million other books are available for Amazon Kindle. Learn more

Vous voulez voir cette page en français ? Cliquez ici.

Sign in to turn on 1-Click ordering.
More Buying Choices
Have one to sell? Sell yours here
Start reading Clean Code: A Handbook of Agile Software Craftsmanship on your Kindle in under a minute.

Don't have a Kindle? Get your Kindle here, or download a FREE Kindle Reading App.

Clean Code: A Handbook of Agile Software Craftsmanship [Paperback]

Robert C. Martin
4.8 out of 5 stars  See all reviews (13 customer reviews)
List Price: CDN$ 51.99
Price: CDN$ 32.75 & FREE Shipping. Details
You Save: CDN$ 19.24 (37%)
o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o
In Stock.
Ships from and sold by Gift-wrap available.


Amazon Price New from Used from
Kindle Edition CDN $25.01  
Paperback CDN $32.75  
Save Up to 90% on Textbooks
Hit the books in's Textbook Store and save up to 90% on used textbooks and 35% on new textbooks. Learn more.
Join Amazon Student in Canada

Book Description

Aug. 1 2008 0132350882 978-0132350884 1
Even bad code can function. But if code isn’t clean, it can bring a development organization to its knees. Every year, countless hours and significant resources are lost because of poorly written code. But it doesn’t have to be that way.

Noted software expert Robert C. Martin presents a revolutionary paradigm with Clean Code: A Handbook of Agile Software Craftsmanship . Martin has teamed up with his colleagues from Object Mentor to distill their best agile practice of cleaning code “on the fly” into a book that will instill within you the values of a software craftsman and make you a better programmer—but only if you work at it.

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. More importantly, you will be challenged to reassess your professional values and your commitment to your craft.

Clean Code is divided into three parts. The first describes the principles, patterns, and practices of writing clean code. The second part consists of several case studies of increasing complexity. Each case study is an exercise in cleaning up code—of transforming a code base that has some problems into one that is sound and efficient. The third part is the payoff: a single chapter containing a list of heuristics and “smells” gathered while creating the case studies. The result is a knowledge base that describes the way we think when we write, read, and clean code.

Readers will come away from this book understanding
  • How to tell the difference between good and bad code
  • How to write good code and how to transform bad code into good code
  • How to create good names, good functions, good objects, and good classes
  • How to format code for maximum readability
  • How to implement complete error handling without obscuring code logic
  • How to unit test and practice test-driven development
This book is a must for any developer, software engineer, project manager, team lead, or systems analyst with an interest in producing better code.

Frequently Bought Together

Clean Code: A Handbook of Agile Software Craftsmanship + The Clean Coder: A Code of Conduct for Professional Programmers + Design Patterns: Elements of Reusable Object-Oriented Software
Price For All Three: CDN$ 102.03

Customers Who Bought This Item Also Bought

Product Details

Product Description

About the Author

Robert C. “Uncle Bob” Martin has been a software professional since 1970 and an international software consultant since 1990. He is founder and president of Object Mentor, Inc., a team of experienced consultants who mentor their clients worldwide in the fields of C++, Java, C#, Ruby, OO, Design Patterns, UML, Agile Methodologies, and eXtreme programming.

Excerpt. © Reprinted by permission. All rights reserved.

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 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.

Inside This Book (Learn More)
First Sentence
You are reading this book for two reasons. Read the first page
Browse Sample Pages
Front Cover | Table of Contents | Excerpt | Index | Back Cover
Search inside this book:

What Other Items Do Customers Buy After Viewing This Item?

Customer Reviews

4.8 out of 5 stars
4.8 out of 5 stars
Most helpful customer reviews
6 of 6 people found the following review helpful
5.0 out of 5 stars This Book Changed Me June 17 2009
I'd been programming for eight years in various languages and technologies when I read this book so I wasn't an absolute beginner; but after I read this book my coding completely changed, and I think for the better.

What impressed me most about this book was the many examples: "Uncle Bob" gave practical before and after examples of applying the principals of clean code. The examples were realistic and worthwhile: he'd take a piece of code, iteratively apply different principals and by the time he was done the code looked, well, clean, both in design and readability.

From what I've heard, what people remember most is the principal of "self-documenting code". Now I too had heard all of that before and I'd seen some terrible "self-documenting" code; however, when Martin explained it--and gave examples--it began to make sense and I've been doing it ever since. Trust me, when _he_ explains it, it makes sense.

The book goes well beyond self-documenting code. I would recommend this book for anyone who codes, but especially for someone with a couple years of, not just writing code, but also reading other people's code; often it's hard to pin down just what is so difficult and clumsy about the code we write and Martin shows us.
Was this review helpful to you?
7 of 7 people found the following review helpful
4.0 out of 5 stars Be a professional Sept. 20 2008
If you want to be inspired to be a true professional programmer, Clean Code is a great book. A variety of topics are covered including naming, comments, formatting, exception handling, testing, and concurrency. Once you've read the book, the reference chapter on smells and heuristics is probably what you'll return to the most.

The common theme that runs through the book is the push to be a true professional when programming. More often than not we get something working and then move on, saying that we'll write the tests or refactor it later. A professional will clean up the mess immediately before moving on to the next task. In this sense the book is inspiring if these goals are in line with yours.

In some ways the book reminds me of Code Complete, but if you already have read that you will still find new content, in particular with the exhaustive examples that show various clean ups including a portion of JUnit. A couple of the examples feel like they go on too long, including an Appendix of 60 pages of a replacement Date class for Java. I just find reading that much code in a book to be more difficult than on-screen.
Was this review helpful to you?
Format:Paperback|Verified Purchase
This book was well written and easy to follow, and it helped me to overcome many of my programming issues simply by teaching me how to write cleaner code.
Was this review helpful to you?
5.0 out of 5 stars Important book Feb. 9 2014
Format:Paperback|Verified Purchase
It is a very important book for every developer. A lot of valuable information in the book. It did teach me new way to have a clean code.
Was this review helpful to you?
5.0 out of 5 stars Read it July 9 2013
Nice book! Easy reading before bed time. Has lots of similarities with 'Code Complete' though I would say is better and gives deeper knowledge.
Was this review helpful to you?
9 of 13 people found the following review helpful
3.0 out of 5 stars Good, not great April 11 2010
By gyas
This book is an OK collection of coding tips, but is not in the same league as Steve McConnell's God-like "Code Complete". This is illustrated by comparing how the two books broach the topic of "how long should a function be?".

Martin writes things like "Functions should hardly ever the 20 lines long ... This is not an assertion that I can justify. I can't provide any references to research that shows that very small functions are better." On the same topic McConnell doesn't merely make unjustified assertions, he states that the optimal function size is 100-200 lines then *does* provide citations to 7 actual studies referenced in a massive 20 page bibliography(!) to affirm his position.
Was this review helpful to you?
5.0 out of 5 stars Five Stars July 16 2014
Format:Paperback|Verified Purchase
Great book, if a bit pretentious at times.
Was this review helpful to you?
Want to see more reviews on this item?

Look for similar items by category