An incredible book that leaves with you a sense of pride in writing good and understandable code. I think that is a topic that you don't see in the programming courses in college a lot. You get teach how to program, that there are an infinity number of ways to get to the same solution, but you never are given a set of standards to improve that solution once you have it. It's more like mash something together, if it works for one or two cases great, move on to the next problem.

There needs to be a sense of pride in the code as the secondary product we are creating (the primary being the product/service). It's pretty much a presentation card for whoever comes after us when we are finished with a project.

There is a movement brewing in the world of professional software development. This movement is concerned not merely with writing functional, correct code, but also on writing good code. Taking pride in code. This movement is the Software Craftsmanship movement, and one of the people near the head of this movement is Robert C. Martin, also known as Uncle Bob.

His book "Clean Code" is, in many ways, an introduction to the concept of Software Craftsmanship and a guide for developers interested in becoming craftsmen. Clean Code is not about only writing correct code, it's about writing code that is designed well, code that reads well, and code that expresses the intent of the author.

The book is essentially divided into two parts. The first part contains Bob's suggestions for writing and maintaining clean code. This includes suggestions on everything ranging from how to properly comment code and how to properly name variables to how to separate your classes and how to construct testable concurrent code. The second part of the book uses the principles in the first part to guide the reader through a few exercises in which existing code is cleaned.

The first part of the book is fantastic. I can't recommend it highly enough for a professional software developer that wishes to elevate him or herself to a higher standard. This guide is excellent, and gave me lots of things to think about while reading it. I could almost feel myself becoming a better programmer as I internalized Martin's advice, and the code I've been writing has been noticeably better since I began following his suggestions.

In the second part of the book, Martin essentially guides us through three projects: a command line argument parser he wrote, a section of the JUnit source code, and a section of source code from SerialDate. Of these, the most detailed guide is Martin's illustration of refactoring the command line argument parser.

These sections all suffered from a fundamental flaw: they were inside a book.

These sections all required reading large amounts of source code. Not just scanning it, but really reading and understanding the code, so that the reader can understand the changes Martin makes to the code. Reading and understanding code is something I do every day as a professional, but I never have to do it from paper.

When I read code, I'm interacting with something, not just reading. I can scroll up and down. If I see a method being used and I wonder how it's written, I can click on it and jump right to the implementation. My IDE shows me symbols in my gutterbar when methods are overridden. I can press a keystroke to pull up a list of just the methods in a source file. I can right click on a method and find its usages immediately. The source code I am reading is something I can push and pull, gaining an understanding of it through interaction.

When source code is printed in a book, you get none of this. To make matters worse, Martin's code samples have absolutely no syntax highlighting applied to them. When I read source code, certain parts are rendered in specific ways that make it easier to pull the information into my brain. Strings and literals are formatted differently, comments are dimmer so I can focus on code, and so on. Code samples in "Clean Code" are just characters, with occasionally bolding used to draw attention to parts that were changed. It's amazing how much syntax highlighting helps make code more comprehensible, even at a completely subconscious level.

A book is, quite simply, not an appropriate medium for a guided code walkthrough. I'd have preferred the content of these sections as perhaps a lecture, with Martin's text done in audio and his code kept on the screen. This would at least prevent me from having to flip back and forth constantly. I didn't get as much out of these sections as I would have liked to, simply because it was so difficult to digest the information it contained in such an awkward, unnatural medium. At the very least, the code samples should have been printed in color, with syntax highlighting.

I can tell that his advice was good and that the refactorings he applied to the code samples in the book made the code far better, but mostly because I've observed these efforts in real life and observed how much they improve code. If I were to encounter Martin's "before" and "after" code in a project I was working on, I undoubtedly would find the "after" code far, far cleaner and more enjoyable to work with. However, since the book format made it so difficult to understand EITHER code sample, it didn't seem like Martin's efforts offered much improvement, even though I know they did.

Despite this frustration, the book is an excellent read, and I'm quite certain it has contributed a great deal to helping me improve as a professional. I can't recommend it enough, especially for Java developers. I just think that most readers will find the final few chapters intensely frustrating - I recommend downloading the code and viewing it in your favorite code editor so that you can comprehend the source code the way you would any other source code.

Good for reviewing most of clean code tips, especially dirty code smells. Well detailed and with sufficient code samples(BTW all the code samples are written in java).
But all along I had problems with accepting some of the rules at the extent that author implies. Even in my opinion some refactoring examples shown in the book were making the code harder to read compared to former state.
I think and probably the writer agrees that clean code is not some sacred thing by itself, but it serves high quality and maintainable software. So as not an experienced developer and one who never had worked on huge code bases. I think some of these rules wont serve the desired goal at least in software with small code base.
Also I think some of the rules don't apply today because we now have more intelligent code editors with better autocompletion and code hinting(showing the docs, definition, etc).
My objections are mostly on parts that the author argues the code is not clean because the lack of expressiveness. I don’t see why I should have long expressive names that any usual developer won't need that degree after a week or two working on the code base and it's not just not needing it, It makes development slower. Small functions that are only used one time won’t smooth development always.
I agree expressiveness helps new coders on first steps, but it makes old developers slower. So I think at the end it's a matter of compromise and it differs case by case. For example in the case of software driven by open source community may be the case that we should make it as easy as possible for newcomers, but when there is a software with permanent team behind it I think we should make it so they can code and work faster. They don't need expressiveness because they are struggling with the code at least every week.
An example which also will bring up what I mentioned as modern code editors is about comments. The writer emphasizes that code should not need comment and it should explain it self. I don’t get it. Now days code editors show variable, functions comments as their documentation then why we shouldn’t use one line comments instead of making the code self expressive by long names, additional functions and etc.
I don't know about others but for me long lines of code is hard to read.

Lots of noise in lines and lines of code.

About half of the advice in this book is not very good and potentially actively harmful and bad. The other half of advice in this book is very good, heck, a must. It is a darned shame that so much of the good is mixed up with the bad.

+ Some really foundational advice to understanding importance of code readability and the whole development process
+ Examples
+ Cute start of chapter pictures
- Advice is a bit outdated for some things
- Tone was too high and mighty
- only java examples with lots of references to specific java technologies that did not age well

Very useful book. It talks about very important points and explains things very well.