- Series: Robert C. Martin Series
- Paperback: 256 pages
- Publisher: Prentice Hall; 1 edition (May 23, 2011)
- Language: English
- ISBN-10: 0137081073
- ISBN-13: 978-0137081073
- Product Dimensions: 6.9 x 0.8 x 8.9 inches
- Shipping Weight: 14.9 ounces (View shipping rates and policies)
- Average Customer Review: 126 customer reviews
- Amazon Best Sellers Rank: #25,842 in Books (See Top 100 in Books)
Enter your mobile number or email address below and we'll send you a link to download the free Kindle App. Then you can start reading Kindle books on your smartphone, tablet, or computer - no Kindle device required.
To get the free app, enter your mobile phone number.
The Clean Coder: A Code of Conduct for Professional Programmers 1st Edition
Use the Amazon App to scan ISBNs and compare prices.
The Amazon Book Review
Author interviews, book reviews, editors picks, and more. Read it now
Frequently bought together
Customers who bought this item also bought
“‘Uncle Bob’ Martin definitely raises the bar with his latest book. He explains his expectation for a professional programmer on management interactions, time management, pressure, on collaboration, and on the choice of tools to use. Beyond TDD and ATDD, Martin explains what every programmer who considers him- or herself a professional not only needs to know, but also needs to follow in order to make the young profession of software development grow.”
Senior Software Developer
“Some technical books inspire and teach; some delight and amuse. Rarely does a technical book do all four of these things. Robert Martin’s always have for me and The Clean Coder is no exception. Read, learn, and live the lessons in this book and you can accurately call yourself a software professional.”
Senior Program Manager
“If a computer science degree had ‘required reading for after you graduate,’ this would be it. In the real world, your bad code doesn’t vanish when the semester’s over, you don’t get an A for marathon coding the night before an assignment’s due, and, worst of all, you have to deal with people. So, coding gurus are not necessarily professionals. The Clean Coder describes the journey to professionalism . . . and it does a remarkably entertaining job of it.”
University of Illinois at Urbana-Champaign
“The Clean Coder is much more than a set of rules or guidelines. It contains hard-earned wisdom and knowledge that is normally obtained through many years of trial and error or by working as an apprentice to a master craftsman. If you call yourself a software professional, you need this book.”
–R. L. Bogetti
Lead System Designer
From the Back Cover
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 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.
Top customer reviews
This feeling only doubled last week when i was waiting outside the operation theater, waiting for doctors to finish an important surgery for a loved one. I wouldn't trust a software developer for such an activity (and we ourselves are to be blamed). Robert C. Martin just goes through experiences of his life/work and explains what lacks in software developers. He uses all of his experience (and trust me, he has got it big time). You get to read him narrate an experience of his and you would bet you faced a similar situation last month.
There aren't days in office, when me and my colleagues don't quote "uncle bob". Uncle bob, in general, and this book, in particular, is a constant source of wisdom for us.
Warning: This book can change your life!
* What is a software professional?
* How does a professional behave?
* How does a professional deal with conflict, tight schedules, and unreasonable managers?
* When, and how, should a professional say, "no"?
* How does a professional deal with pressure?
The subtitle, A Code of Conduct for Professional Programmers puts some significant weight on this book. And The Clean Coder is a pretty darn good book. For example, the first chapter is "Professionalism", and the first section is "Be Careful What You Ask For" with the following question:
"What would happen if you allowed a bug to slip through a module, and it cost your company $10,000? The nonprofessional would shrug his shoulders, say 'stuff happens', and start writing the next module. The professional would write the company a check for $10,000!"
Martin's comments on taking responsibility, and on saying "no" (and also on saying "yes" and meaning it) are spot on. His chapter on estimation is very good as well, emphasizing the distinction between an estimate and a commitment and introducing PERT estimates, which I seem to have managed to miss before.
The list of good things about The Clean Coder goes on and on, including handling pressure, teams, and the development of a professional programmer from an apprenticeship. Further, the whole mass is leavened by Martin's war stories, dating back into the dim mists of antiquity and dealing with both his successes and failures.
The book, which is not that big and a quick read, covers a wealth of advice at a high-level, with pointers to learn more. Many of those topics, as I have tried to point out above, are all over professionalism for the programmer. Things like responsibility, handling pressure, and mentoring. But there is other advice in the book which does not have the same pedigree. Some of it would appear to be a "nice-to-have" rather than a requirement. Then there are things that seem to be Martin's personal opinions. And then, there is stuff that is just bizarre.
I don't want to get into the case for test-driven-development here. It works, well. (But then, so do code inspections, seemingly even better, and I have plenty of evidence for that. Yet it doesn't get the same press. And no, pair programming is not the same thing.) But the vast majority of working code in the wild was not produced by TDD. I can lay hands on more than a few very professional programmers who think unit tests are not worth their opportunity costs, to put it mildly. I will go as far as saying that unit testing is a good idea, and that TDD, in a lot of cases, gives me more confidence in my code. But I cannot go along with making it a requirement for professional programming.
Appendix A, Tooling, has a nice list of useful development tools. "Tomato" time management is interesting. "When the heat is on, find an associate who is willing to pair program with you." Ok. I personally think "craftsmanship" is a good way to describe good programming. Most of the time, anyway. On the other hand, with all respect to Uncle Bob, if I tried, I could also track down a fair number of embedded and safety-critical software developers who regard the whole "agile" thing with a mixture of disbelief and horror.
But what about this:
"Much has been written about the hyper-productive state known as "flow." Some programmers call it "the Zone." Whatever it is called, you are probably familiar with it. It is the highly focused, tunnel-vision state of consciousness that programmers can get into while they write code....
"Here's a little hint from someone who's been there and back: Avoid the Zone.... Code written in the Zone may come out faster, but you'll be back to visit it more....
"One of the big benefits of pair programming is that it is virtually impossible for a pair to enter the Zone...."
Let me just say that I don't have my copy of Mihály Csíkszentmihályi's books handy. But I do seem to recall that a reduced error rate is one of the definitive benefits of flow. Further, Martin's description of the Zone as "tunnel-vision" and "uncommunicative" directly contradict Csíkszentmihályi's description of flow in team sports. On the other hand, Martin's comments also contradict both the common description of pair programming's feel, and Martin's own comments about "focus-manna".
And then there's the "Coding Dojo". Now look, I am a big fan of toy problems. They're fun, they're relaxing, working on one is roughly the equivalent of a situation comedy: everything gets wrapped up in 22 minutes. Better, they're good ways to try out something new, to explore a problem, or to isolate some issue so that you can examine it without getting lost in the surrounding weeds. But when Martin writes,
"In 2005 I attended the XP2005 Conference in Sheffield, England. I attended a session with the name Coding Dojo led by Laurent Bossavit and Emmanuel Gaillot. They had everyone open their laptops and code along with them as they used TDD to write Conway's Game of Life....
"A programming kata is a precise set of choreographed keystrokes and mouse movements that simulates the solving of some programming problem. You aren't actually solving the problem because you already know the solution. Rather, you are practicing the movements and decisions involved in solving the problem."
Well, after that, I've got nothin'. Sorry.
In the end, Clean Coder has a lot of very good advice, a lot of good philosophy about programming professionalism. It also has many entertaining stories. But I, as a (possibly delusional) professional programmer, just don't see it as a grand manifesto.
In The Clean Coder, "Uncle Bob" shares extremely practical wisdom on topics ranging from "when and how to say no" to "testing your software". Not much fluff here. Just a lot of readily applicable content. And for the content that you can't apply immediately, the time investment is clearly worth it. Amateurs will gain great insight into the disciplines required to be a professional programmer.
My favorite thing about this book is Martin's anecdotes. I feel like I have such a better grasp on what software development was like decades ago. (And a greater appreciation for it.) Furthermore, Martin's words are full of great wisdom for dealing with people as a programmer - an aspect that makes this book extremely unique.
Did I mention it's a very easy read with a conversational tone? Whether you're an amatuer programmer or an experienced developer, this book is for you.
Most recent customer reviews
Uncle Bob's brilliantly combined his technical and soft skills recommendations in this...Read more
So I haven't read the whole book yet, I am around the quarter of it, but I have to tell you: it's great.Read more