Enjoy fast, free delivery, exclusive deals, and award-winning movies & TV shows with Prime
Try Prime
and start saving today with fast, free delivery
Amazon Prime includes:
Fast, FREE Delivery is available to Prime members. To join, select "Try Amazon Prime and start saving today with Fast, FREE Delivery" below the Add to Cart button.
Amazon Prime members enjoy:- Cardmembers earn 5% Back at Amazon.com with a Prime Credit Card.
- Unlimited Free Two-Day Delivery
- Instant streaming of thousands of movies and TV episodes with Prime Video
- A Kindle book to borrow for free each month - with no due dates
- Listen to over 2 million songs and hundreds of playlists
- Unlimited photo storage with anywhere access
Important: Your credit card will NOT be charged when you start your free trial or if you cancel during the trial period. If you're happy with Amazon Prime, do nothing. At the end of the free trial, your membership will automatically upgrade to a monthly membership.
Buy new:
$42.74$42.74
FREE delivery
Ships from: Amazon.com Sold by: Amazon.com
Buy used: $35.25
Download the free Kindle app and start reading Kindle books instantly on your smartphone, tablet, or computer - no Kindle device required.
Read instantly on your browser with Kindle for Web.
Using your mobile phone camera - scan the code below and download the Kindle app.
Follow the author
OK
The Clean Coder: A Code of Conduct for Professional Programmers 1st Edition
Purchase options and add-ons
Programmers who endure and succeed amidst swirling uncertainty and nonstop pressure share a common attribute: They care deeply about the practice of creating software. They treat it as a craft. They are professionals.
In The Clean Coder: A Code of Conduct for Professional Programmers, legendary software expert Robert C. Martin introduces the disciplines, techniques, tools, and practices of true software craftsmanship. This book is packed with practical advice–about everything from estimating and coding to refactoring and testing. It covers much more than technique: It is about attitude. Martin shows how to approach software development with honor, self-respect, and pride; work well and work clean; communicate and estimate faithfully; face difficult decisions with clarity and honesty; and understand that deep knowledge comes with a responsibility to act.
Readers will learn
- What it means to behave as a true software craftsman
- How to deal with conflict, tight schedules, and unreasonable managers
- How to get into the flow of coding, and get past writer’s block
- How to handle unrelenting pressure and avoid burnout
- How to combine enduring attitudes with new development paradigms
- How to manage your time, and avoid blind alleys, marshes, bogs, and swamps
- How to foster environments where programmers and teams can thrive
- When to say “No”–and how to say it
- When to say “Yes”–and what yes really means
Great software is something to marvel at: powerful, elegant, functional, a pleasure to work with as both a developer and as a user. Great software isn’t written by machines. It is written by professionals with an unshakable commitment to craftsmanship. The Clean Coder will help you become one of them–and earn the pride and fulfillment that they alone possess.
Review
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 codeHow to write good code and how to transform bad code into good codeHow to create good names, good functions, good objects, and good classesHow to format code for maximum readabilityHow to implement complete error handling without obscuring code logicHow to unit test and practice test-driven developmentThis book is a must for any developer, software engineer, project manager, team lead, or systems analyst with an interest in producing better code.
About the Author
Robert C. Martin (“Uncle Bob”) has been a programmer since 1970. He is founder and president of Object Mentor, Inc., an international firm of highly experienced software developers and managers who specialize in helping companies get their projects done. Object Mentor offers process improvement consulting, object-oriented software design consulting, training, and skill development services to major corporations worldwide. Martin has published dozens of articles in various trade journals and is a regular speaker at international conferences and trade shows.
He has authored and edited many books, including:
- Designing Object Oriented C++ Applications Using the Booch Method
- Patterns Languages of Program Design 3
- More C++ Gems
- Extreme Programming in Practice
- Agile Software Development: Principles, Patterns, and Practices
- UML for Java Programmers
- Clean Code
A leader in the industry of software development, Martin served for three years as editor-in-chief of the C++ Report, and he served as the first chairman of the Agile Alliance.
Robert is also the founder of Uncle Bob Consulting, LLC, and cofounder with his son Micah Martin of The Clean Coders LLC.
- ISBN-100137081073
- ISBN-13978-0137081073
- Edition1st
- Publication dateMay 13, 2011
- LanguageEnglish
- Dimensions6.9 x 0.8 x 9 inches
- Print length256 pages
Frequently bought together

Similar items that may ship from close to you
From the brand
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
Product details
- Publisher : Pearson; 1st edition (May 13, 2011)
- Language : English
- Paperback : 256 pages
- ISBN-10 : 0137081073
- ISBN-13 : 978-0137081073
- Item Weight : 14.1 ounces
- Dimensions : 6.9 x 0.8 x 9 inches
- Best Sellers Rank: #169,438 in Books (See Top 100 in Books)
- #10 in Software Design & Engineering
- #148 in Microsoft Programming (Books)
- #184 in Software Development (Books)
- Customer Reviews:
Important information
To report an issue with this product or seller, click here.
About the author

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.
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 Amazon-
Top reviews
Top reviews from the United States
There was a problem filtering reviews right now. Please try again later.
The Clean Coder helps demonstrate how programmers can conduct themselves as professionals, removing that black-box quality and holding themselves to standards as other professionals do so they garner the same respect from their peers and can help others do more with technology.
I’ll talk about some of the lessons that really resonate with me:
In the forward, Matthew Heusser relays a story about how his colleague, Joe, considers “estimates” from the technical team and “estimates” from the legal team with completely different mindsets. In short, Joe considered legal estimates to be final, whereas technical estimates were negotiable. Why weren’t estimates from the two teams treated equally? In my career, I’ve seen the same thing many times, largely stemming from three reasons. First is the assumed “magic” that non-technical people think programmers wield. Throughout the book, Martin explains how to remove the veil of mystery regarding said magic. Second is that I’ve run across others that compared us with their profession and made some assumptions, such as, though a harsher example, we’re being lazy or noncommittal. Here, the author discusses how to address such assumptions when confronted with them. Third, and the most important part that we can influence, is the tech person’s mindset and approach to work. From the text, the programmer learns how to craft their own mindset and workflows to handle these. In essence, we can’t make things perfect, but we control a lot of parameters to make things better.
The first three chapters cover the conduct that a software developer professional should exhibit. A recurring theme within all three chapters is that software developers should take responsibility for what they say and do. Martin gracefully simplified this down to: how/why to say “no” and how/why to say “yes.” For example, if a developer agrees to a timeline, then they should make the timeline. If there are risks or unknowns on something you’re defining a timeline for, don’t agree to it, but rather just agree to what you can commit to if possible. The key is to not let yourself get bullied into agreeing to something you know you can’t meet with confidence. Others will build their own schedules and commitments around what you say, and there may be serious repercussions and loss of face if you fail to deliver. If you’re not as accurate as possible, you’ll erode the trust you have with your colleagues.
Along with controlling and defining your commitments, you need to take responsibility for your work output. Specifically, being a professional means that you certify and guarantee that your work output functions. For example, accountants ensure that their accounts balance when they finish closing out the books monthly, quarterly, and year’s end. If they left discrepancies, they would soon find themselves out of work. However, developers seem to be able to deliver questionable code or features that just plain don’t work, again and again. I understand why: development is hard. There are a lot of moving pieces and people in a software development project; as a result, there are a lot of rules that get balanced when you go in and change something. None of that takes away from the fact that developers lose trust of their peers when they fail to deliver working solutions for the tasks assigned to them. They’ll probably remember the failure (their label, not yours) instead of the nuanced “whys” that caused that failure.
Luckily, software developers have tools available to them to prevent this from happening, but only if the tools are actually put to use. Martin’s philosophy around testing is something with which I completely agree. The only way you can truly know that what you’ve added or changed doesn’t break everything else on a project – regardless of size – is to test it and have a structured, scalable approach to testing. Manual testing takes time, sometimes A LOT of time, and you leave a lot to chance that way. Hence automation. When automated, a test can be written once and then just be executed. It makes it trivial to repeatedly ensure that your code matches all the criteria it needs to meet. (Note: I wouldn’t recommend this approach across the board, particularly if an MVP, pilot system, or feature with a lot of changing specifications is being created, which is quite common with my startup customers. For something mature, scalable, and maintainable in a financially feasible manner, it’s required.)
Martin’s discussion of “expected criteria” is another area that is really important for developers to understand and put to use. Ultimately, a customer or stakeholder will have to accept the software that a developer builds. When is the software done? What do clients judge the system’s success by? What aspects of the software do they value, and how do they prioritize what they value? To address this, I've always operated from the mindset of: the software is done when the customer tells me it's done. Part of that determination is working with the customer to define the acceptance criteria, though that can be difficult if the customer is non-technical or busy. Even high-level criteria are helpful, such as "Search for a product, and buy it” or “Load fast.” That’s fine so long as the stakeholders are open to iterations later to arrive at what they truly want. Conversely, the criteria could be very specific. Ideally, the developer helps the customer put more definition on their acceptance criteria throughout the process. The more quantitative, the better. The developer is finished with the work when they deploy or deliver the software or functionality that meets all the acceptance criteria. In conclusion, it’s not so important how the acceptance tests are written even though there are best practices; what is important is that you and the client know what is “done” and agree to it.
The book is chock-full of other applicable advice as well, from numerically-driven ways to handle estimates to suggestions for interacting with colleagues. All of the recommendations align to the goal of helping developers comport themselves as professionals so they’ll be treated as such by other professionals. It’s very important because our work is nebulous and our profession is new. I highly recommend this book to anyone who wants to be a professional software developer for the long-term or works a lot with them.
The book consists of of 14 chapters. Each chapter covers an aspect of software development and describes Bob's opinion on what it means to be a professional in that particular aspect. The first chapter is an overview. Chapter 2 and 3 talk about the ability to say NO! and not being pressured or talked into unrealistic promises and about how serious you ought to take it if you do say yes.
Chapter 4-8 discuss development-focused practices, from coding (4), to test-driving (5), practicing your skills (6), working with the customer by acceptance testing (7) and different strategies for testing (8). Each of the chapters is short that it doesn't really talk about the concepts, but it points out some important parts and explains why it is important for professionals to act a certain way.
Chapter 9-11 are more time-practices. Starting from Time Management (9), Estimation (10) and dealing with pressure (11). These chapters also strongly relate to the "Saying No" chapter (2) of not making unrealistic commitments and the "Saying Yes" (3) chapter of letting "Yes!" actually mean something. Especially the pressure chapter is one that the reader probably ought to read several times :)
Chapter 12-13 discuss about professionals working together with other people, with customers and with other developers. Chapter 13 is a little off as it covers a bit more on organizational structure to make efficient teams than how to act as a professional developer.
Chapter 14, the ending chapter, covers mentoring and craftsmanship. It stresses (a topic Bob often repeats) how silly it is that even McDonalds employees are better mentored in their job than an average SW developer. It envisions a better way of growing great developers in organizations.
The Clean Coder is an important book as there aren't many book on the topic of behavior of individual developers. Especially the topics related to developer behavior under pressure and making and avoiding commitments are, in my experience, of most importance for good software development... yet rarely discussed.
The book is an important book, yet I felt disappointed at times. Most topics are covered really shallow (keeping the book small) and at times it felt Bob was just cherry-picking a couple of practices he felt important. Also, at times, I felt the book was inconsistent with itself. For example, one of the things that annoyed me, is that in Chapter 1 he talks about professionalism and how one aspect of professionalism is to "know your field". Yet, in the chapter of professionalism he doesn't at all refer back to earlier attempts on the same subject. He doesn't refer to After the Gold Rush: Creating a True Profession of Software Engineering (DV-Best Practices) or about the attempts of IEEE and ACM of defining our profession. If you are writing on the subject, and tell people they should "know the field" then at least you ought to refer back to the earlier developments in "the field". Similarly, I felt the book is seriously lacking references to further study on the important practices that are covered.
The Clean Coder is also a very personal book. Bob is obviously the Clean Coder in the title and the definition of professionalism is his definition of being a professional. The book is full of stories from Bob's long career that helped him reach these conclusions... what it means to be a professional. I enjoyed the stories from his career a lot and it makes the book at times, almost an autobiography...
Conclusion. At times, I though this is definitively a 5 star book, yet at times I felt it is just average and shallow and doesn't deserve more than 3 stars. In the end, for me, it was the topic of unrealistic commitment that forms the skeleton of the book that I decided on 4 stars. It is less good as his earlier 2 books Clean Code: A Handbook of Agile Software Craftsmanship and Agile Software Development, Principles, Patterns, and Practices . But it is definitively an important book and worth reading, especially when you want to help building a true profession.
Top reviews from other countries
No matter how good of a coder you are, following the advice in this book will make you a better professional and more employable. Absolutely worth every penny.
We find lot of good books and material out in the world on how to write better algorithms and how to write better code, which design patterns to apply when etc., but there is rarely any material which covers on how to be a real professional software engineer. This book is based exactly on that and covers various points like :
1. how to be considered as a real professional rather than just another software engineer.
2. how and when to say NO / YES
3. How to practise outside our daily work hours to become professional at what we do.
4. How to write a code that is fail proof and clean - Testing (many times developers tend to finish the product first and ignoring writing the unit tests or any tests, the book clearly explains why we need to focus on writing tests)
5. How to manage Time and pressure - which is most common in the software profession where the work timings can be crazy and nothing might go as planned.
Very Engaging and simple to read. You will enjoy reading the book as it has lot of stories from Authors life told in an intresting way and also be left with good amount of knowledge.
The book offers advice which is much needed and ususally takes years of working experience to realise the same.
Highly recommend to all the coders/programmers/software engineers, to improves ourselves and become a real professional.









