Buy new:
$44.99$44.99
FREE delivery:
Thursday, Nov 17
Ships from: Amazon.com Sold by: Amazon.com
Buy used:: $42.10
Download the free Kindle app and start reading Kindle books instantly on your smartphone, tablet, or computer - no Kindle device required. Learn more
Read instantly on your browser with Kindle Cloud Reader.
Using your mobile phone camera - scan the code below and download the Kindle app.
Follow the Authors
OK
Clean Code: A Handbook of Agile Software Craftsmanship 1st Edition
| Robert C. Martin (Author) Find all the books, read about the author, and more. See search results for this author |
| Price | New from | Used from |
|
Audible Audiobook, Unabridged
"Please retry" |
$0.00
| Free with your Audible trial | |
|
Spiral-bound
"Please retry" | $78.99 | $78.88 |
Enhance your purchase
Noted software expert Robert C. Martin, presents a revolutionary paradigm with Clean Code: A Handbook of Agile Software Craftsmanship. Martin, who has helped bring agile principles from a practitioner’s point of view to tens of thousands of programmers, 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 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 Codeis 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
- What “smells” and heuristics can help you identify bad code
- ISBN-109780132350884
- ISBN-13978-0132350884
- Edition1st
- PublisherPearson
- Publication dateAugust 1, 2008
- LanguageEnglish
- Dimensions7 x 1.1 x 9.2 inches
- Print length464 pages
Frequently bought together

More items to explore
Functions should either do something or answer something, but not both.Highlighted by 3,199 Kindle readers
The proper use of comments is to compensate for our failure to express ourself in code.Highlighted by 2,855 Kindle readers
FUNCTIONS SHOULD DO ONE THING. THEY SHOULD DO IT WELL. THEY SHOULD DO IT ONLY.Highlighted by 2,624 Kindle readers
From the Publisher
From the Preface of "Clean Architecture"
“…The rules of software architecture are the rules of ordering and assembling the building blocks of programs. And since those building blocks are universal and haven’t changed, the rules for ordering them are likewise universal and changeless.
But one thing has changed: Back then, we didn’t know what the rules were. Consequently, we broke them, over and over again. Now, with half a century of experience behind us, we have a grasp of those rules.
And it is those rules—those timeless, changeless, rules—that this book is all about.”
— Robert C. "Uncle Bob" Martin
|
|
|
|
|
|
|---|---|---|---|---|---|
| Clean Code: A Handbook of Agile Software Craftsmanship | The Clean Code: Practical Advices for the Professional Programmer | Clean Craftsmanship: Desciplines, Standards, and Ethics | Clean Agile: Back to Basics | Clean Architecture: A Craftsman's Guide to Software Structure and Design | |
| Best agile practices of cleaning code “on the fly” Software Craftsmanship. | Endure and succeed amidst swirling uncertainty and nonstop pressure. | Picks up where Clean Code leaves off, outlining additional ways to write quality and trusted code you can be proud of every day. | A clear and concise guide to basic Agile values and principles. Perfect for those new to Agile methods and long-time developers who want to simplify approaches for the better. | Direct, no-nonsense answers to key architecture and design questions. | |
| "It is the best pragmatic application of Lean principles to software I have ever seen in print." —James O. Coplien, Founder of the Pasteur Organizational Patterns project | “Some technical books inspire and teach; some delight and amuse. Rarely does a technical book do all four of these things.” — George Bullock | ". . . [A] timely and humble reminder of the ever-increasing complexity of our programmatic world and how we owe it to the legacy of humankind--and to ourselves--to practice ethical development.” — Stacia Heimgartner Viscardi, CST & Agile Mentor | “What is in the world of Agile development is nothing compared to what could be. This book is Bob’s perspective on what to focus on to get to that ‘what could be.’ And he’s been there, so it’s worth listening.” — Kent Beck | "A good architecture comes from understanding it more as a journey than as a destination, more as an ongoing process of enquiry than as a frozen artifact." — Kevlin Henney |
Pick Up Where Clean Code Leaves Off
"As software developers, we have to continually solve important problems for our employers, customers, colleagues, and future selves. Getting the app to work, though difficult, is not enough, it does not make you a craftsman. With an app working, you have passed the app-titude test. You may have the aptitude to be a craftsman, but there is more to master. In these pages, Bob expresses clearly the techniques and responsibilities to go beyond the app-titude test and shows the way of the serious software craftsman."
— James Grenning, author of Test-Driven Development for Embedded C and Agile Manifesto co-author
Editorial Reviews
From the Back Cover
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
About the Author
Product details
- ASIN : 0132350882
- Publisher : Pearson; 1st edition (August 1, 2008)
- Language : English
- Paperback : 464 pages
- ISBN-10 : 9780132350884
- ISBN-13 : 978-0132350884
- Item Weight : 1.46 pounds
- Dimensions : 7 x 1.1 x 9.2 inches
- Best Sellers Rank: #5,356 in Books (See Top 100 in Books)
- #1 in Software Design & Engineering
- #2 in Software Testing
- #5 in Software Development (Books)
- Customer Reviews:
About the authors

Robert Cecil Martin (colloquially known as Uncle Bob) is an American software engineer and author. He is a co-author of the Agile Manifesto.
Bio from Wikipedia, the free encyclopedeia. Photo by Tim-bezhashvyly (Own work) [CC BY-SA 4.0 (http://creativecommons.org/licenses/by-sa/4.0)], via Wikimedia Commons.

I am a principal software engineer at Domino Data Lab, an expert in MLOps, and a long-time member of the Scala community. I am also the author of several books:
-- "Programming Scala, Third Edition", a practical book for experienced software developers that introduces this important, modern programming language.
-- "Programming Hive", a comprehensive guide to Hive, the SQL tool for Hadoop (coauthors: Ed Capriolo and Jason Rutherglen).
-- "Functional Programming for Java Developers", a succinct introduction for Java developers to the concepts of functional programming, where I motivate its importance and demonstrate how to use FP concepts in Java programs.
You can find out more about me at these web sites:
-- http://deanwampler.com: My personal home page.
-- http://polyglotprogramming.com: Presentations, white papers, etc.
-- https://deanwampler.medium.com: My blog.
-- https://twitter.com/deanwampler
-- https://linkedin.com/in/deanwampler
My "off-line" interests include photography, hiking, skiing, and other mountain sports, cooking, and reading, including books that aren't about software!
Customer reviews
Customer Reviews, including Product Star Ratings help customers to learn more about the product and decide whether it is the right product for them.
To calculate the overall star rating and percentage breakdown by star, we don’t use a simple average. Instead, our system considers things like how recent a review is and if the reviewer bought the item on Amazon. It also analyzed reviews to verify trustworthiness.
Learn more how customers reviews work on AmazonReviewed in the United States on November 3, 2018
-
Top reviews
Top reviews from the United States
There was a problem filtering reviews right now. Please try again later.
Ideally, each developer takes charge of their own education and is constantly improving their skillset, an aspect that Martin covers in The Clean Coder. I view it as an important part of my job to help my team improve. To do so, I distill a lot of written material down to actionable components and provide that to my development team. Concepts from Clean Code have become very helpful guides for them. Below are a few of my favorite takeaways.
The first is what Martin calls The Boy Scout Rule: “Leave the campground a little cleaner than you found it.” It’s a great concept, not only because it's simple to follow, but also because it has broad applicability and can be used on any project. Essentially, when a team member works on a piece of code, they should aim to improve it somehow by the time their task is finished. A few examples of this among many are: fixing an unclear variable name, breaking up a large function into smaller functions, or cleaning up a conditional for improved clarity. With everyone on the team doing this, the code improves over time and everyone feels responsible for the code whether they wrote it personally or not. Even if something can’t be addressed immediately, developers are encouraged to log the issues they see.
Another of my favorite takeaways is the Three Laws of TDD, a concept I was able to quickly roll out to the team as a framework to follow for how TDD should be conducted on a project. This virtually ensures that all of your product code has test coverage. It also helps make most of your code SOLID (https://en.wikipedia.org/wiki/SOLID_%28object-oriented_design%29), since code that is built in this fashion is structured with SOLID concepts in mind. This is a must for effective testing.
Finally, the topics of proper identifier names and commenting really resonated with me and my team. In our company, we tend to “adopt” existing codebases – projects that have already been started by other developers whose code is of widely varying quality. If we're lucky, it's structured well and demonstrates best practices and approaches in how it's constructed. Unfortunately, the code is sloppy at times and requires some TLC to get it in shape. A part of that process is understanding what the existing application does. As Clean Code correctly outlines, many comments are superfluous or even plain wrong and misleading. As a team, we don’t blindly trust the accuracy of existing comments and instead go right to the application’s code to determine what it does. This is where proper naming comes into play. With good names, the code reads like comments or as a narrative of what the application does, nullifying most needs for additional commenting. Simply put, the code comments itself. We also use refactoring tools to improve names and clean up comments as we go. Of course, by doing so, we’re also applying the Boy Scout Rule.
Overall, Clean Code is a wonderful book with much useful and immediately-applicable information for developers of all levels. If you're looking for a book that will help make you a better developer, this will.
I've been in the industry for 22+ years, but just started to reread this book. I consider it to be one of the top books _any_ software engineer, developer etc. should definitely read.
Now, I disagree with some of things strongly. Uncle Bob is quite biased towards OOP, and in general issues presented
are more complex and I'd claim that the only rule in software engineering is "it depends". In general my biggest complaint is that almost all of the rules I see anyone present come with a cost, with Clean Code it sounds like they are free. Eg. I really, really like simple, short functions/methods that do only one thing, but there is a cost of adding extra levels of abstraction. Even though I do prefer that over hundreds of thousands of lines of code in one method, it doesn't come as free (even though benefits far outweighs costs, given proper execution).
The other example, just to mention an example, is on naming variables. In general I agree that long, good names are much better than short cryptic ones, but for short expressions like one-line transformations are often _easier_ to read if variables are short, and their scope is limited to that one line. As an example, any experienced Python developer would immediately recognize `squares = [ n**2 for n in numbers if even(n) and n > 10]` while using longer names would just make general form (where var names don't matter). Many guides nowadays describe this principle as "variable name length should be in relation to scope of the variable" which is a good rule, though I believe even that has exceptions.
But having said that, I'd claim things would be in much, much better condition in software industry if people read this book. And definitely he has much more impressive track record than me, so I'm ready to accept that while I disagree with some of the things, I could very well be wrong (and still blind to it). SOLID principles are really good to understand, and the first one of those applies to _everything_, even if you use functional programming paradigm. Same goes for comments; comments are eventual lies, and developer should restrict IMO those to explaining _why_, not _what_.
I read the book first time when I had been 5+ years in the industry or so, and it definitely made me a better developer. And while I now see rationale behind the rules in the book a bit lacking given complexity and variance in common problems developers face (mainly every solution has a cost), I still consider the book one of the best ones. Just get it and read it.
Top reviews from other countries
Bei den beigefügten Bildern sieht man das Original (von der Firma) und das hier bestellte Buch (PDF Druck)
Reviewed in Germany 🇩🇪 on November 7, 2017
Bei den beigefügten Bildern sieht man das Original (von der Firma) und das hier bestellte Buch (PDF Druck)
Wie bereits von anderen Personen festgestellt, habe auch ich leider eine billige Kopie des Originals erhalten - vermutlich ein Druck der PDF-Version. Der Druck ist schlecht, das Format ist unnötigerweise sehr viel größer, das Cover ist verschwommen/verpixelt, kein bzw. weißer Buchrücken und -rückseite.
Hierfür über 29€ zu verlangen grenzt an Betrug. Ich habe das Exemplar unmittelbar zurückgeschickt. Schade.
Reviewed in Germany 🇩🇪 on April 21, 2018
Wie bereits von anderen Personen festgestellt, habe auch ich leider eine billige Kopie des Originals erhalten - vermutlich ein Druck der PDF-Version. Der Druck ist schlecht, das Format ist unnötigerweise sehr viel größer, das Cover ist verschwommen/verpixelt, kein bzw. weißer Buchrücken und -rückseite.
Hierfür über 29€ zu verlangen grenzt an Betrug. Ich habe das Exemplar unmittelbar zurückgeschickt. Schade.
Before reading this book, I recommend having a good understanding of Java and Object-Oriented programming. Don't forget Abstract classes, Interfaces, and Polymorphism.
In my opinion, it has more than 100 pages in excess.The appendixes and the chapter 14 (Refinement) don't contribute to anything. They are just boring. Also, I think that chapter 13 (Systems) could seem a little bit complex for beginners. It needs a very specific knowledge of Java, with concepts like EJB, JNDI, Proxies, and so on.
On the other hand, every concept is explained accurately with lots of examples. In addition, the "Smells and Heuristics" chapter summarizes the essence of this book very well.














