HomeGroupsTalkMoreZeitgeist
Search Site
This site uses cookies to deliver our services, improve performance, for analytics, and (if not signed in) for advertising. By using LibraryThing you acknowledge that you have read and understand our Terms of Service and Privacy Policy. Your use of the site and services is subject to these policies and terms.

Results from Google Books

Click on a thumbnail to go to Google Books.

Clean Code: A Handbook of Agile Software…
Loading...

Clean Code: A Handbook of Agile Software Craftsmanship (edition 2008)

by Robert C. Martin (Author)

MembersReviewsPopularityAverage ratingMentions
1,3112514,381 (4.27)1
A good book to read for any coder - perhaps not as thorough as Code Complete but much more effective than Pragmatic Programmer.

This book's biggest strength is that it includes tons of code examples, including some fairly long and in depth ones. Instead of just listing rules or principles of clean code, many of the chapters go through these code examples and iteratively improve them. The rules and principles fall out of this process and the reader is a part of developing them, which is an effective way to learn.

I also liked the justification for why clean code matters in the intro chapters. However, there was not enough discussion of real world trade offs. The book brushes them aside and claims that the programmer should *always* write the most clean code possible; what is not mentioned is to what extent to do this and when. In fact, the book compares code to poetry and art and makes a point to mention that neither is ever done. And yet, everyone needs to ship at some point. So when is code not just clean, but clean enough?

Some downsides: the chapters have different authors, so a few are weaker than others. Also, the book is too tailored to Java and imperative/OO programming. Similar to Code Complete, this book would benefit from discussing functional programming, which addresses many of the lessons/problems.

Some fun quotes from Clean Code:


We want the factory running at top speed to produce software. These are human factories: thinking, feeling coders who are working from a product backlog or user story to create product.

Yet even in the auto industry, the bulk of the work lies not in manufacturing but in maintenance—or its avoidance. In software, 80% or more of what we do is quaintly called “maintenance”: the act of repair.

You should name a variable using the same care with which you name a first-born child.

Quality is the result of a million selfless acts of care—not just of any great method that descends from the heavens.

You are reading this book for two reasons. First, you are a programmer. Second, you want to be a better programmer. Good. We need better programmers.

Remember that code is really the language in which we ultimately express the requirements.

LeBlanc’s law: Later equals never.

Michael Feathers: I could list all of the qualities that I notice in clean code, but there is one overarching quality that leads to all of them. Clean code always looks like it was written by someone who cares. There is nothing obvious that you can do to make it better. All of those things were thought about by the code’s author, and if you try to imagine improvements, you’re led back to where you are, sitting in appreciation of the code someone left for you—code left by some- one who cares deeply about the craft.

Language bigots everywhere, beware! It is not the language that makes programs appear simple. It is the programmer that make the language appear simple!

The ratio of time spent reading vs. writing is well over 10:1.

Books on art don’t promise to make you an artist. All they can do is give you some of the tools, techniques, and thought processes that other artists have used. So too this book cannot promise to make you a good programmer. It cannot promise to give you “code-sense.” All it can do is show you the thought processes of good programmers and the tricks, tech- niques, and tools that they use.

The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that.

Functions should do one thing. They should do it well. They should do it only.

Every system is built from a domain-specific language designed by the programmers to describe that system. Functions are the verbs of that language, and classes are the nouns. This is not some throwback to the hideous old notion that the nouns and verbs in a requirements document are the first guess of the classes and functions of a system. Rather, this is a much older truth. The art of programming is, and has always been, the art of language design.

Master programmers think of systems as stories to be told rather than programs to be written.

The proper use of comments is to compensate for our failure to express ourself in code. Note that I used the word failure. I meant it. Comments are always failures. We must have them because we cannot always figure out how to express ourselves without them, but their use is not a cause for celebration.

"Objects are abstractions of processing. Threads are abstractions of schedule.” —James O. Coplien

Concurrency is a decoupling strategy. It helps us decouple what gets done from when it gets done.

Boolean arguments loudly declare that the function does more than one thing.

Names in software are 90 percent of what make software readable.


( )
  brikis98 | Nov 11, 2015 |
English (20)  Hungarian (3)  Spanish (1)  Dutch (1)  All languages (25)
Showing 20 of 20
Cuando lo leí me ayudó mucho con mi iniciación a la programación, más concretamente con el lenguaje de programación Java. Este libro (y muchos de por entonces) asentó las bases de lo que a dia de hoy se conoce como "buenas prácticas" en el ámbito del desarrollo. ( )
  diegocorral | Mar 14, 2024 |
NF
  vorefamily | Feb 22, 2024 |
Code is clean if it can be understood easily – by everyone on the team ( )
  muhammadishaque | Aug 17, 2023 |
Great principles for code writing. I can't say I agree with everything, but it's a lot of (good) food for thought. ( )
  zeh | Jun 3, 2023 |
I wanted to love this book, but instead I just sort of liked it. This book is a member of the extensive genre of books on how to write clean code. It sits alongside books like Code Complete by Steve McConnell[1] and many others. Where Clean Code promised to differentiate itself was in the use of three case studies -- about a third of the book -- showing Martin's code cleanup techniques in action.

However, I was disappointed by that section. As someone who codes and reviews code professionally, the case studies were not particularly enlightening. As seems obvious in retrospect, watching someone clean-up code in fairly straightforward ways is not interesting if you do and see that everyday. What I really wanted was a book on being a better code reviewer with advice on how to spot areas for improvement and convince others of the value of those improvements.

The examples could be useful for someone who isn't in a code-review-heavy environment. Martin does a reasonably good job of taking code that may seem reasonable on the surface and improving its readabilty. That said, his comments indicate that he often has a higher opinion of the cleanliness of his end result than I do.

As for the general advice and discussion of how to make clean code, I agree with a lot of his tips and disagree with others. Code cleanliness is an area where the core of just-plain-good ideas is surrounded by a nimbus of sometimes contradictory standards that people pick and choose from. The details of what you choose from the nimbus generally does not matter so much as consistency. (Of course, the real trouble occurs when people don't agree on what belongs in the core and what belongs in the nimbus.)

The book definitely was not a bad read, but it did not fit my needs.

[1] Still my favorite in the genre. ( )
  eri_kars | Jul 10, 2022 |
I have very mixed feelings about this book. Early on, it made me quite mad. But somewhere in the middle, it suddenly started to make sense. By the end, even though I still didn't agree with everything, I really appreciated the point that it's trying to make, and can agree with it.
Don't get me wrong, there are plenty of problems: so many of the examples are either bogus or have glaring problems of their own, there's a lot of bloat and back-patting in the prose, and to say this book is programming language agnostic is a massive lie. There are large sections devoted to the most Java-centric issues and examples, and it renders a lot of the advice from these sections meaningless for anyone using a different language.
My recommendation: start with the last chapter. If you feel like anything it says doesn't make sense or is unjustified, go back and read the related section. Reading the whole thing is a recipe for frustration. ( )
  nitemice | Dec 28, 2020 |
I finally got around to reading Clean Code by Robert C. Martin (Uncle Bob). It is often high on lists of the best books for software development, and for good reason. Clean Code is an excellent book that all programmers should read. Here is what I liked and didn’t like about it.

ORGANIZATION
The books is divided into four parts. Chapters 1 to 14 go through the basics, including naming, functions, formatting, comments and error handling. Then there are three example programs that are refactored to follow the recommendations given in the first part.

The three example programs are a command-line argument parser, a part of JUnit, and SerialDate, a class for date handling. The examples are quite extensive (together almost a hundred pages), with a lot of source code. All these (and all examples throughout the book) are written in Java.

Next is a chapter called “Smells and Heuristics”, which lists problems in code (and the solutions) in the form of 66 rules.

Finally there is appendix A, with more on concurrency, and appendix B, which has the complete source code for the third example program (SerialDate, almost 60 pages of program listing).

WHAT I LIKED THE MOST
Small. This is the one-word summary of the whole book. Functions and classes should be small (no, even smaller than that). It is much easier to make sure a function does only one thing if it is very small. Dividing the logic up in many small functions also gives you more opportunities to insert meaningful names that explain what is going on.

Niladic and monadic functions. The fewer arguments a function takes, the better (a niladic function takes zero arguments, a monadic one, and a dyadic two). I hadn’t thought much about the number of arguments before, but Uncle Bob makes a convincing case for using very few.

Flag arguments. A flag argument to a function is a boolean argument that controls what should be done. This is really an indication that the function should be split up in smaller parts.

Error handling. The argument for using exceptions for error handling instead of returning error codes is that it is much easier to separate the error handling from the regular logic. Also, using unchecked exceptions (instead of checked) avoids cascading changes when a new exception is added deep down in a hierarchy.

Newspaper Metaphor. The source file should be organized like a newspaper article, with the highest level summary at the top, and more and more details further down. Functions called from the top function come directly below it, and so on down to the lowest level and most detailed functions at the bottom. This is a good way to organize the source code, even though IDE:s make the location of functions less important, since it is so easy to navigate in and out of them.

Javadoc only for API:s. The recommendation is to only use Javadoc for documenting API:s that are exposed externally. Internally in a system, Javadoc documentation usually only results in unnecessary noise. I have seen this problem a lot, and I completely agree with this advice.

Long refactoring examples. The refactoring of the three example programs was quite valuable because it showed how to apply the recommendations in practice, and how the refactorings interact. This is often missing from other books. The disadvantage is that it can be pretty hard to follow when you don’t have an IDE to help you navigate and search.

WHAT I DIDN’T LIKE
Concurrency chapter and appendix. This chapter and appendix felt a bit out of place in the book. I also didn’t like the advice on instrumenting the code to try to find threading issues. In my experience, you don’t find multi-threading bugs that way. Instead, the best way is proper load testing, where the software is in heavy use in realistic scenarios.

Chapters 11 (Systems) and 12 (Emergence). These two chapters, despite promising titles, didn’t contain much of interest. They can easily be skipped without missing out on much.

State to reduce the number of arguments. In order to reduce the number of arguments a method needs, member variables are sometimes introduced instead. While this reduces the number of arguments, it also forces you to examine how the member variable is used in the rest of the class before you have a complete understanding of what the method does. This in my mind is worse, even if the class is small. I prefer the functional style, where it is enough to know the input arguments to have a complete understanding of what will happen.

No emphasis on dynamic error information. When an exception is thrown, it should always contain as much dynamic information as possible, to help in debugging. For example, if a network connection fails, include the port number and IP address the connection was intended for. Without this information, trouble shooting is a lot harder. Unfortunately, this is not mentioned at all in the book.

Wildcard imports. Rule J1 advocates importing a whole package rather than individual classes if two or more classes are needed from the package. However, then your program can break when a class is added to a package you import (more in e.g. this StackOverflow question). A long list of explicit imports at the beginning is not a problem in my view, it is easy to skip over.

CONCLUSION
There is a lot more good information in this book than I have been able to cover here. You can also tell that the advice is based on decades of experience developing real life software systems. I rate this book as one of the top three books on software development (the other two are Code Complete and The Pragmatic Programmer), and I think all programmers should read it.

From review on my blog: https://henrikwarne.com/2015/01/03/book-review-clean-code/ ( )
  Henrik_Warne | Dec 13, 2020 |
Reading this book is akin to reading about how to sterilize instruments in the 1880s: boil everything including the linens, dressings, etc. The advice in the book will be familiar to anyone who has ever read anything relating to programming proficiency (is it a wonder that you should name your variables so they make sense later? How about comments?) The problem is that the examples in the book are incredibly specific for the Java language and are difficult to apply elsewhere. It's akin to sitting with radiation, alcohol, and antiseptic solutions and being told "nope, you need to boil". I think the only reason this book has such a high reputation is because folks go into it thinking there is something they need to find in there in order to make their code better and much like a horoscope they find any nugget of useful information in there and feel like they've achieved coding perfection.

Please do yourself a favor and seek out some of the other books in this area that can give you better guidelines. Better still, find the ones that are tailored to the language you're using and use those to learn best practices. ( )
  craigmaloney | Mar 21, 2020 |
This is a must read for any cs professional ( )
  shubhamchaudhary | Jan 27, 2020 |
There are some good tidbits in there. Nothing earth-shattering, and nothing new (if you spend some time looking around for things like this). Now, had I read this 'way back when', I suspect I would have enjoyed much more. ( )
  CraigTreptow | Dec 9, 2019 |
A good book to read for any coder - perhaps not as thorough as Code Complete but much more effective than Pragmatic Programmer.

This book's biggest strength is that it includes tons of code examples, including some fairly long and in depth ones. Instead of just listing rules or principles of clean code, many of the chapters go through these code examples and iteratively improve them. The rules and principles fall out of this process and the reader is a part of developing them, which is an effective way to learn.

I also liked the justification for why clean code matters in the intro chapters. However, there was not enough discussion of real world trade offs. The book brushes them aside and claims that the programmer should *always* write the most clean code possible; what is not mentioned is to what extent to do this and when. In fact, the book compares code to poetry and art and makes a point to mention that neither is ever done. And yet, everyone needs to ship at some point. So when is code not just clean, but clean enough?

Some downsides: the chapters have different authors, so a few are weaker than others. Also, the book is too tailored to Java and imperative/OO programming. Similar to Code Complete, this book would benefit from discussing functional programming, which addresses many of the lessons/problems.

Some fun quotes from Clean Code:


We want the factory running at top speed to produce software. These are human factories: thinking, feeling coders who are working from a product backlog or user story to create product.

Yet even in the auto industry, the bulk of the work lies not in manufacturing but in maintenance—or its avoidance. In software, 80% or more of what we do is quaintly called “maintenance”: the act of repair.

You should name a variable using the same care with which you name a first-born child.

Quality is the result of a million selfless acts of care—not just of any great method that descends from the heavens.

You are reading this book for two reasons. First, you are a programmer. Second, you want to be a better programmer. Good. We need better programmers.

Remember that code is really the language in which we ultimately express the requirements.

LeBlanc’s law: Later equals never.

Michael Feathers: I could list all of the qualities that I notice in clean code, but there is one overarching quality that leads to all of them. Clean code always looks like it was written by someone who cares. There is nothing obvious that you can do to make it better. All of those things were thought about by the code’s author, and if you try to imagine improvements, you’re led back to where you are, sitting in appreciation of the code someone left for you—code left by some- one who cares deeply about the craft.

Language bigots everywhere, beware! It is not the language that makes programs appear simple. It is the programmer that make the language appear simple!

The ratio of time spent reading vs. writing is well over 10:1.

Books on art don’t promise to make you an artist. All they can do is give you some of the tools, techniques, and thought processes that other artists have used. So too this book cannot promise to make you a good programmer. It cannot promise to give you “code-sense.” All it can do is show you the thought processes of good programmers and the tricks, tech- niques, and tools that they use.

The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that.

Functions should do one thing. They should do it well. They should do it only.

Every system is built from a domain-specific language designed by the programmers to describe that system. Functions are the verbs of that language, and classes are the nouns. This is not some throwback to the hideous old notion that the nouns and verbs in a requirements document are the first guess of the classes and functions of a system. Rather, this is a much older truth. The art of programming is, and has always been, the art of language design.

Master programmers think of systems as stories to be told rather than programs to be written.

The proper use of comments is to compensate for our failure to express ourself in code. Note that I used the word failure. I meant it. Comments are always failures. We must have them because we cannot always figure out how to express ourselves without them, but their use is not a cause for celebration.

"Objects are abstractions of processing. Threads are abstractions of schedule.” —James O. Coplien

Concurrency is a decoupling strategy. It helps us decouple what gets done from when it gets done.

Boolean arguments loudly declare that the function does more than one thing.

Names in software are 90 percent of what make software readable.


( )
  brikis98 | Nov 11, 2015 |
A very practical guide to improving the quality of the code you write. Mostly focused on unit testing and refactoring, including examples of gradually improving real projects.

Main idea: you cannot expect to find the best code structure from the first attempt, so plan to refactor it multiple times even as you write it, and provide the test coverage to do that with confidence. Otherwise, you end up with a pile of code that only sort-of-works, and that no-one ever dares to touch in order to make it better, including yourself.

Also lots of good general advice on code structure and style. Useful even if you do not agree with all of it. ( )
  valdanylchuk | Aug 26, 2015 |
Essential book if you were-are-want to be- a programmer. ( )
  JavierRiestra | Aug 21, 2014 |
An excellent guide for the teams and the engineers which take care of agility, productivity and on the other hand quality in software craftsmanship. "The Clean Code" shows us the "clean" way how to work together effectively in a team and produce maintainable software in the long term and not only functional code stacks. The book points out how important the aspects like readability and consistency are - even in comments - in order to reduce bugs and increase robustness . You'll also find lots of refactoring examples by author which show us how to apply these rules iteratively and still improve our source code. The only critic about the book is the concurrency chapter. It is in my opinion superfluous since the concurrency issues and the best practices respectively can not be covered within a chapter and for that reason it remains superficial. But it is still one of the book which i would read more than once and keep it on my desk while i am coding. ( )
  ebagdemir | Apr 7, 2013 |
En TDD se tiene la precondición que el desarrollador sabe crear código limpio en términos de OO. El refactoring (como un paso del TDD) requiere buenas prácticas de escritura de código. Este libro le ayudará a eso
  agilenature | Jun 23, 2011 |
I don't tend to read a ton of books that pertain to my profession. In the software development field, technology moves along at such a fast pace that most tech books are outdated almost before they hit the shelves. The books I do enjoy in this genre are those that espouse some theory, techniques or ideas that are timeless and are applicable despite the technology. This is one of those such books. Every developer should read this one. Most of the concepts inside are common sense ideas, but ones that you may not realize are important. Definitely one that will gain a space on my shelf and which I shall refer back to from time to time as a refresher or to clarify some position. Great stuff, if you develop software, buy this book. ( )
  harpua | Dec 28, 2009 |
A really great book to read. I think it's a must read for software developers, for beginners as well as professionals. It helps a lot with the implementation details of software development. It answers questions for you like:
- When to write documentation?
- What are the steps to take when refactoring?
- How important is naming in my code.

The concepts are very well written. After reading the book and recommending it to my co-workers, it really felt the quality of our code was improving by applying the priciples written in the book. Like I said: a must read for every team involved in creating software! ( )
1 vote epragt | Dec 27, 2009 |
I would recommend this as a must read for Java programmers, along with Joshua Bloch´s 'Effective Java'.

Programmers using other languagens should also read, since the concepts listed in this book apply to a broad range of platforms. ( )
  caike | Jan 12, 2009 |
.. ( )
  Kevin.Parent | Oct 21, 2012 |
a
  Ovi_Books | Jun 6, 2010 |
Showing 20 of 20

Current Discussions

None

Popular covers

Quick Links

Rating

Average: (4.27)
0.5
1 1
1.5
2 1
2.5 2
3 29
3.5 2
4 76
4.5 8
5 90

Is this you?

Become a LibraryThing Author.

Penguin Australia

An edition of this book was published by Penguin Australia.

» Publisher information page

 

About | Contact | Privacy/Terms | Help/FAQs | Blog | Store | APIs | TinyCat | Legacy Libraries | Early Reviewers | Common Knowledge | 203,208,347 books! | Top bar: Always visible