- File Size: 42806 KB
- Print Length: 464 pages
- Simultaneous Device Usage: Up to 5 simultaneous devices, per publisher limits
- Publisher: Prentice Hall; 1 edition (August 1, 2008)
- Publication Date: August 1, 2008
- Sold by: Amazon.com Services LLC
- Language: English
- ASIN: B001GSTOAM
- Text-to-Speech: Enabled
- Word Wise: Not Enabled
- Lending: Not Enabled
- Amazon Best Sellers Rank: #18,057 Paid in Kindle Store (See Top 100 Paid in Kindle Store)
Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin Series) 1st Edition, Kindle Edition
Use the Amazon App to scan ISBNs and compare prices.
Black Lives Matter: Books to help you be antiracist.
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.
Customers who bought this item also bought
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.
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.
Would you like to tell us about a lower price?
There was a problem filtering reviews right now. Please try again later.
Every programmer regardless of experience should read this book. Thanks!
Much of the information in this books is eye opening, particularly the chapters on functions, classes, and code smells. However, a serious problem is that this book is very, very Java-centric, and it is clearly a product of its 2009 copyright date. Many of the chapters have been made moot (PEP8 and Prettier making the formatting chapter largely obsolete, for example), and a few aren't totally applicable to any other language.
Note about buying a new, physical version from Amazon: don't. The book will be damaged in shipping as it just comes in a padded envelope and will be dog-eared like a used book before you receive it. See my picture.
I've heard that originally, the print quality was ok, well, it's not anymore.
It's still readable, but I would never buy it if I new about the print quality.
Should've read other reviews.
The code examples are written in Java and are there to show how to refactor code based on the principles and reasoning within the book.
This is not a book that I take as a specific do this or else, more of a guide that explains why you should consider writing code in the way described.
Essentially the lesson is to create code that is small, has a specific purpose and does that one thing.
When functions or methods begin to stray into doing multiple things spin those code pieces off on their own and repeat.
What I get from this book is a mindset or way of thinking about programming. To create code that is cohesive, is small, does not have unnecessary parts. When these principles are broken find a way to refactor or eliminate the additional pieces. It is not just about taking away or keeping code small but adopting a way of thinking about the design of the program and how each piece interacts with the other parts.
The suggested line lengths of functions mentioned and other very specific examples is more where your critical thinking comes into play. I do not program in Java so many of the language specific scenarios do not apply to me. in some languages you just can't have or do some of the things suggested. Though as a general rule of thumb I find the examples helpful and when I mean general rule of thumb I do not mean a specific line count or size but a simplistic do as little as possible to achieve the goal. Simplify. Simplify. Simplify.
I purchased and received the 16th printing of this book, published February 2016.
There are no weird formatting or printing issues with the book as others have mentioned.
If you have the ability to reason and think critically, being able to adapt examples and suggestions to your own style and language then I highly recommend this book. The contents are NOT common sense and do not come naturally to the uninitiated. The book does take you by the hand in a certain way leading you from the process of just make the program work to thinking about the logic design and function of your programs.
When you are in situations where redesign is not possible the principles learned from this book will help you to refactor when possible and write new code that is better, smaller, tighter. Making you a better more valuable programmer.
Clean Code goes into the depths of the problem. Robert Martin takes you through pages upon pages of code to make the points clear and relevant to real world problems. Too many books give simple examples that are difficult to make meaningful.
Overall this is a great book that I recommend to programmers at all levels. You will learn something new (even though it's an "older" book).
Top international reviews
In all the book is still perfectly usable and the quality issues do not affect the paper quality or resolution of the pages themselves. The only real downsides are the ugly front cover and larger/heavier than necessary physical form. The situation regarding intellectual property is unclear.
My verdict: buy it anyway, but be aware its not the Real McCoy.
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.
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.
On the other hand the book is a useful reference which I have found helpful as I have been programming for over 50 years and needed so guidance on modern best practice.
I studied computer science and many of the concepts like proper naming of variables and short functions with a single responsibility are not exactly new but nonetheless, I found also many new and useful tips I haven’t thought about before. For example, how to deal with third party libraries properly.
The rather complex topic about concurrency in application is also touched and some good testing approaches are covered in the appendix.
All the examples are based on Java which is not really an issue since the ideas are independent of the programming language used. That said, some chapters deal explicitly with Java specific libraries and are less useful if your language of choice is something else. Other than that, I can recommend this book to all software developers and even more so to Java developers.
- page size is bigger than normal with a lot of unnecessary margin (making the book heavier and cumbersome to read),
- low press quality (words are not very black)
- the cover picture is pixelated (maybe not that visible from pictures but pretty clear to the naked eye).
I found it slow and managed to condense everything that I found useful into 3 A4 pages on word. I found the example uninspiring considering they were showcasing the reason I was reading the book.
I recommend this book to anyone doing a career in any type of tech development, these programming principles are shared across all fields of programming.
It truly has made me a better coder, and a more reflective one, taking the extra time to fully understand a problem, and then figure out the solution.
This book has given me the courage to take up new projects in my work, enforcing better coding standards and techniques.
The chapter on comments is worth the price of the book alone. I have worked in places over the last few years, where comments have been encouraged to explain the code, rather than writing code that explains itself. Another great chapter is the one on functions and the advice to keep them small is especially good and compelling. As I look back over the table of contents now, every chapter that describes how to improve an aspect of code is an absolute mine of good advice.
The final few chapters contain a number of refactorings. One on an application from the ground up and the others on existing code written by other people. This is the only place where the book got gratuitous and I must admit I skipped most of the final refactoring.
The final chapter is a summary of the advice given in the rest of the book and something I will find myself referring to again and again.
If you've read Test Driven Development and The Pragmatic Programmer, make sure you read Clean Code next.
Taking a series of real world examples -- open source projects with significant user bases, including FitNesse and JUnit -- a series of worked examples take us from good, or at least adequate, code, to a form which is better factored, and easier to read, with the steps along the way clearly marked. Yes, even some of Kent Beck's code is put under the microscope, and carefully polished that extra stage or two more.
The reader is cautioned that, without working long hours to follow these examples, this will be just another of those feel-good books. I don't quite agree -- spending just a little time to follow the transformations, and then reflecting on one's own outpourings should be enough to make this a feel-bad book. All the sins from obscurely named variables to sprawling functions that gaily mix abstraction levels, we've all done them (especially programming in FORTRAN on minicomputers with slow stacks and a rule of thumb that 1 call ~ 40 loc in terms of performance).
The maxim to take from the book is based on Baden-Powell's "Try and leave this world a little better than you found it", and owes to the same school of thought as "whenever you are in the garden, pull at least one weed". The meat of the book is in distinguishing what are the weeds from the intended crop.
So read it, understand the examples, and then refer to it often -- like the other titles mentioned, it is a reference work, and should join them as among the most thumbed on your bookshelf.