Clean Code: A Handbook of Agile Software Craftsman

Robert C. Martin Series

by Robert C. Martin

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.

Genres: Programming, Computer Science, Technology, Software, Technical, Nonfiction, Coding

431 pages, Unknown Binding

First published January 1, 2007

About the author

Robert Cecil Martin, commonly called Uncle Bob, is a software engineer, advocate of Agile development methods, and President of Object Mentor Inc. Martin and his team of software consultants use Object-Oriented Design, Patterns, UML, Agile Methodologies, and eXtreme Programming with worldwide clients.

He was Editor in Chief of the C++ Report from 1996 to 1999. He is a featured speaker at international conferences and trade shows.

Reviews

[Oana Sipos]

These are rather notes than a review while reading:

1. Use very descriptive names. Be consistent with your names.

2. A function should not do more than one thing.

3. SRP (Single Responsibility Principle): a class or module should have one, and only one, reason to change.

4. Stepdown rule: every function should be followed by those at the next level of abstraction (low, intermediate, advanced).

5. A long descriptive name is better than a short enigmatic name. A long descriptive name is better than a long descriptive comment.

6. The ideal number of arguments for a function is zero (niladic). Next comes one (monadic), followed closely by two (dyadic). Three arguments (triadic) should be avoided where possible. More than three (polyadic) requires very special justification and then shouldn't be used anyway.

7. Flag arguments are ugly. Passing a boolean into a function is loudly proclaiming that this function does more than one thing. It does one thing if the flag is true and another one if the flag is false.

8. Write learning test when using third-party cody to make sure it behaves the way you expect it to. And if codebase changes in time, at least you find out early enough.

[Francis Fish · Rating 3 out of 5]

The first half of this book is well worth a read. Then I was reminded of Martin Fowler's (I think) comment that the original Design Patterns Elements of Reusable Software book was a response to the limitations of C++. It dovetailed so well into Java because Java has a lot of the same annoying limitations, and in some ways is even harder.

The latter section of the book contains some worked examples that I didn't always agree with because they seemed to be totally over done. A lot of the refactorings came from limitations in the language and even then felt arbitrary and not that "clean", more like differences of opinion.

In light of this I think the book would have been better titled Clean Java, and then we'd all know where we stand. Have to say I was disappointed by the case studies. I think if you're a jobbing Java programmer you will get a real benefit from this book. I use dynamic languages like Ruby and most of the problems described in need of refactoring just never happen.

[Vladimir · Rating 4 out of 5]

This book makes some very good points, sometimes taking them to extreme ("Never write functions longer than 15 lines! Never write functions with more than three arguments!"). Some of these points were quite new and useful for me - YMMV. It's too Java-specific in a few places, and reading the last refactoring chapter on a kindle was quite a challenge, but otherwise it was well worth a read. At least I got a clear picture of how I want to refactor a big piece of my current project after reading this :)

[Jerry · Rating 3 out of 5]

I had a tough time deciding between 3 or 4 stars.

The book should be called Clean Java Code. Some of the concepts definitely translate to other languages, but it uses Java for all of the examples and some of the chapters are dedicated to Java-specific issues.

I consider many of the the suggestions to simply be common sense, but I've worked with enough of "other people's code" to realize they don't necessarily agree. With all of that said, I'd definitely recommend the book to Java developers at the beginner and intermediate levels.

[Rod Hilton · Rating 4 out of 5]

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.

[Nariman · Rating 5 out of 5]

If you are a programmer, you must read it! full of good examples of how to write clean and readable code.

[Carl-Eric · Rating 3 out of 5]

Many good points in this book. Unfortunately, almost all of them are overdone. Yes, you should write short functions, if possible. Yes, you should have functions that do one thing.

But no, "one thing" does not mean you should tear an algorithm apart into twenty little funclets that make no sense on their own.

Basically, like another reviewer wrote, the first part of the book raises many good points, and the second part of the book then merrily applies these points way beyond their usefulness. Read the book, but keep your brains turned on and be alert.

[David · Rating 2 out of 5]

I was extremely underwhelmed with Clean Code! As other reviewers have noted, this book completely Java-centric and incredibly narrow in its object-oriented focus. Nowhere on the front cover, spine, or back cover is this mentioned at all.

Clean Code also relies heavily on other published works. In the case of Fowler's Refactoring and the "Gang of Four"'s Design Patterns, I wasn't too put off by it. These are pretty standard reference books and I have them on my shelf.

But the really irritating references were to Martin's previous book, Principles, Patterns, and Practices. Martin uses terminology he defined in that book (SRP, OCP, and DIP) and refuses to re-define it when he uses it in this book! I found that to be extremely arrogant and short-sighted. Was I expected to own that book already or to be so impressed with this book that I would immediately run to my local bookstore and purchase it? Fat chance!

(Of course you can look up SRP, OCP, and DIP online. But that's entirely besides the point!)

Lastly, I think the greatness of Martin's own examples in this book (and his apparent high opinion of his abilities) are highly debatable. I would never crow about my own work with such gusto - I've been humbled far too many times. The Introduction is also rather grandiose - with lots of bluster about how difficult it will be to read the book and how carefully the reader will need to study the master's examples. I've worked through the examples. That introduction is pompous bullshit.

To end on a high note: though other authors have already tackled this material and done it better, that's not to say that there isn't plenty of great advice in this book. There is. There's tons of good advice in this book. The "Prefer Polymorphism to If/Else or Switch/Case" tip in Chapter 17 was advice I was able to apply immediately to a project I was working on at the time and that alone was worth reading the book.

[Amir Tesla · Rating 4 out of 5]

Great great book on principles of clean code.

The only problem with the book was that it’s obsessively written for Java. Even though, there are still many principles you can apply to any other languages from C to Python.

Although have to say, you have to do your own research for applicability of the principle in your target language. For instance, the inversion of control (IoC)and Dependency Injection (DI) are quite common and intrinsic to Java, but it is not as straightforward in Python (because of dynamic nature of python and duck typing)

In any case, This book is an absolute must for any programmer seeking to perfect their craft.

[Marta · Rating 3 out of 5]

The first half of the book is a worthy read: it contains the principles of clean code and practical advice to follow. Unfortunately the code examples are very Java-specific and overall dated. Much of the advice is phrased in the way of object oriented languages, which limits the overall applicability of the concepts, even though they are general enough.

I am a long time C# programmer, and lately have been doing a lot of LabView development. LabView has classes but the overhead of writing them is huge, so while I am OO to the core, even I balk at creating lots of small classes in LabView. I actually did not expect much in this book that I did not already know, and I was right: only the sections on concurrency offered some new information. I mainly just decided to listen to this when I ran across it on Hoopla, to see if this could be a book I could hand to new programmers. (When I acquired The Art of Unit Testing: With Examples in .NET, I thought I would learn something, but I knew all that stuff already. It was amazingly useful though as a handout to anyone who programmed but did not unit test.) Alas, this is not so. The principles are good but the examples are overworked and outdated. And Java is verbose and often clunky. Thank god for saving me from Java.

Some of my favorite coding principles:
- You will be reading the code way more than writing it. Write code that is easy to read.
- Writing code that is easy to write is easy. To make it easy to read takes work. Re-factor your code early and often.
- Have unit tests written before you refactor.
- Use a dependeny injection (a.k.a. inversion of control) framework to write testable code.
- Your classes and methods should have a single responsibility.
- Choose good names. Descriptive ones. Long ones. For classes, methods, variable names.
- Your code should be self-documenting. Comments are only necessary if something cannot be expressed in code, or if it is an API between systems.
- Write short methods and classes. If your code is long, you need to break it up, instead of inserting comments.

Overall, this is not a complete waste of time for new programmers, but there are better ones out there.

[David · Rating 2 out of 5]

This is a book that one could get started on the idea of "good code" - clean, readable, elegant, simple, easy-to-test, etc. It has the usual stuff that you'd expect - good naming convention, testable code, single responsibility, short classes, short methods - but I feel like it takes them on overdose, going to extremes (IMHO) such as setting short explicit lengths, forbidding certain constructs, and what seems like refactoring for the sake of it.

I'd actually recommend other books like the Pragmatic Programmer or Code Complete; there's something about the way this book reads that irks me. I think it's more useful to highlight the attributes that clean code should have (which this book does do), then it is to declare outright what is "good" and what is "bad" (even in subjective areas like readability, comments, and formatting).

To their credit, the author(s) did state right out at the start that these are their very personal preferences, so that's all right - I'm just disagreeing on some of the more subjective areas.

Also a plus are a few actual and simple scenarios/use cases to show code clean up in action, but they aren't exactly really tricky bits of code, but rather straightforward examples - very good for developers new to the concept of clean code, but less so for developers already familiar with the basic ideas.

[Fahad Naeem · Rating 3 out of 5]

I started reading it after a lot of recommendations but it wasn't gone up to the standards.
Clean Code is about writing code which is not only understandable to the code him/herself but to the others as well.

Robert Martin mainly used a lot of JAVA code which is not applicable to other languages like Python and JAVASCRIPT. This book should not be this much lengthy and other languages must be covered so that every programmer can benefit from it.

I was looking forward to learn more about refactoring but he did not cover it in detail which was disappointing as well.

Robert discussed in detail about naming convention which applies to every programming language in general and which were quite helpful.

[Babak Ghadiri · Rating 3 out of 5]

به نظرم این کتاب برای برنامه‌نویسان تازه کار خوبه. خیلی از چیزهایی که توش گفته شده رو به شکل تجربی میشه بهشون رسید. من یه فصلش رو که توش یک تکه کد رو ریفکتور میکرد رو چاپ کردم که خط به خط و با دقت بخونم، ببینم زمان ریفکتور چی تو ذهنش میگذره. بعد دیدم چیز خیلی عجیبی نبود و من هم اگه بودم شبیه همین کارها رو میکردم. کلا هم فصل آخرش
(Smells and Heuristics)
رو بخونید خوبه.
به نظرم کتاب ریفکتورینگ آقای فاولر خیلی کتاب باارزشتریه در این زمینه

[Paul Sochiera · Rating 4 out of 5]

I would consider this an essential read for software developers. This book conveys the fundamentals of writing clean code, whose importance cannot be overstated.

I subtracted one star, because it often assumes the reader knows varios concepts and it uses lots of unexplained abbreviations. I am an incredibly unexperienced developer and that is probably the primary reason for this discrepancy; that being said I generally expect books to not require prerequisite knowledge.

[Matt Wheeler · Rating 5 out of 5]

every line of code I've ever written has been trash

[SeyedMostafa Meshkati · Rating 4 out of 5]

کلین کد عملا از اون دسته کتاب‌هایی در دنیای نرم‌افزار هست که یک دانش بنیادی به ما می‌دن و خب طبیعتا از نظر خیلی‌ها « ماست رید » حساب می‌شه، در کنار کتاب‌هایی مثل ریفکتورینگ و پراگماتیک پروگرمر و تی‌دی‌دی بای اگزمپل و غیره.

خوندن این کتاب آورده‌های زیادی داره، از آشنا شدن با یک‌سری مفاهیم اولیه گرفته تا مباحثی که هر فصل بهش پرداخته می‌شه، از اون طرف تلاش خوبی شده تا مباحث به صورت صرفا تئوری در نیان و فرد با فرآیند اصلاح هم آشنا بشه یا حداقل قبلش تو کانتکست قضیه قرار بگیره.
یک سری موارد شاید توشون اغراق شده باشه یا بعضا مواردی دیگه کاربرد نداشته باشن ( با توجه به امکانات IDEها و غیره )، اما به نظرم حتی همین اغراق‌ها هم مفیدن. همینا هم باعث می‌شن یک سری موارد مهم تو ذهن آدم محکم‌تر بشن. کلا توضیح زیادتر از نظر من تو این کتابا خیلی مفیده، باعث می‌شه پایه‌های اون قضیه تو ذهن آدم محکم‌تر بشن.

مثال‌های کتاب به زبان جاوا هستن، اما در اکثر موارد مفاهیمی که مطرح می‌شن قابل نگاشت به زبان‌های دیگه‌ن و از این نظر مشکل خاصی وجود نداره. درصد خیلی خیلی کمی از کتاب هست که بشه گفت اسپسیفیک مختص زبان جاوا هست ( از روی دسته بندی بخش سوم بخوایم بریم عملا ۳/۶۶م قضیه ) ولی خب تو متن کتاب شاید بشه گفت ۱۰ درصد.

اما یک موردی که به نظرم داون‌ساید کتاب حساب می‌شه، تو نحوه‌ی تمیز‌کاری‌ها خصوصا در بخش دوم کتاب هست ( بخش‌هارو در ادامه توضیح می‌دم ). به این صورت که یک سری تغییرات، به نظرم واقعا « بهبود » نیستن، صرفا « از یک مسیر دیگه رفتن » و یا از یک مسیر دیگه پیاده کردن جزئیاتن. از روی متن و توضیحات آنکل‌باب هم مشخص هست قضیه، عموما دلایل آورده شده برای اون قسمت‌ها ضعیف هستن. این شاید تو ذهن بعضی مخاطب‌ها قضیه رو بد نشون بده. از اونجایی که این کتاب یه جورایی داره به شکل یک « بایبل » در میاد ( که خوب هم هست ) بعضیا ممکنه این قسمت‌هارو زیادی جدی بگیرن و خودشون رو مجبور کنن حتما حتما به همین شکل و از همین طریق برن و یه مقداری تعصب بی‌جا اینجاها شکل بگیره.

- توضیح استراکچر کتاب:
همونطوری که تو مقدمه‌ی کتاب اومده، کتاب سه بخش داره. بخش اول مفاهیم رو توضیح می‌ده مقدار کمی حالت پرکتیکال داره، مثلا تکه‌کد‌هایی برای درک بهتر قضیه توش آورده شدن.
بخش دوم به استفاده از این مفاهیم رو میاره و شروع به تمیز کردن یک سری پروژه می‌کنه، اینجا دیگه با یک‌سری تکه‌کد طرف نیستیم و عملا یک کلاس یا پروژه رو به صورت کامل تحلیل می‌کنیم. با دقت خوندن این بخش می‌تونه جذاب باشه.
و بخش سوم هم که یک تک فصل هست، مواردی که تو بخش دوم اصلاح می‌شدن رو به صورت حدودا دسته‌بندی شده به عنوان رفرنس قرار داده که این هم هر چند وقت یک بار خوندنش می‌تونه کمک کنه به ماندگاری مفاهیم کتاب.

- اضافات و پ.ن:
یادش بخیر، عید سالی بود که کنکور داشتیم. یه برنامه نویس اندرویدی بود به اسم کریم ابوزید، این بنده‌خدا توی گوگل‌پلاسش یه پست گذاشت که عکس کتاب کلین کُد بود و ازش تعریف کرد. اون موقع دانش برنامه‌نویسی من خیلی کم بود، مشارکت نصفه و نیمه تو یه پروژه‌ی اندروید و برنامه‌نویسی در سطح مدرسه و ور رفتن با پی‌اچ‌پی و غیره احتمالا ماکسیموم تجربه‌ی من از برنامه نویسی بود. اونجا بود که یه روزی رو به جای تست شیمی و ریاضی زدن گذاشتم برای خوندن این کتاب ( با اون وضعیت اسفناک زبانم :))‌ ). بعد کنکور دوباره اومدم سراغش، یادمه اون موقع حتی نمی‌دونستم اصن فرق این کتاب با کلید کدر چیه و اولش داشتم اون رو می‌خوندم :)) اصن نصف چیزایی که می‌خوندم رو شاید درست حسابی درک هم نمی‌کردم، چون از قبل به عنوان یه چلنج باهاشون برخورد نکرده بودم، اصن نمی‌دونستم این حرفا واقعا مهم هستن و بیگ‌دیل حساب می‌شن.
ولی خب خلاصه بعد چند سال همت کردم و کامل از اول خوندمش :)) این خوش‌حال کننده‌س برام. یه جورایی یه سری خاطره‌هایی حین خوندنش برام زنده می‌شد که باعث می‌شد دقایقی رو از کتاب دور بشم. کاش یه دور دیگه اون دوران رو تجربه می‌کردم :)

[Yevgeniy Brikman · Rating 5 out of 5]

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.

[Karolina Konduracka · Rating 3 out of 5]

Spodziewałam się dowiedzieć więcej 🤷🏼‍♀️
+ romantyzowanie czytania / pisania „czystego kodu” no totalnie nie jest dla mnie xD

[Hannah Cassie · Rating 4 out of 5]

the theory part has a lot of good ideas, not sure if all really that practical in big pipelines but definitely something to think about. The practical part I'm going to do separate since it's all java focused.

[Kosala Nuwan Perera · Rating 4 out of 5]

I had a tough time deciding whether I really liked or It was amazing. I liked the writing style of the book. Its simple, clean, and well crafted.

First few chapters of the book makes good practical advice from naming variables-functions-classes to writing functions to testing. Most of the smells and heuristics I found in these chapters can be found in real-world as well.

Complexity kills. It sucks the life out of developers, it makes products difficult to plan, build, and test. - Ray Ozzie, CTO, Microsoft Corporation

In the next few chapters of the book contains some very good points. Some of them are quite new and very useful for me when applying design principles (such as SRP, OCP, DRY, SOC) to keeping the code base small, simple, and clean.

Most freshman programmers (like most grade-schoolers) don't follow this advice particularly well. They believe that the primary goal is to get the program working. Once it's "working", they move on to the next task, leaving the "working" program in whatever state they finally got it to "work". Most seasoned programmers know that this is professional suicide.

These parts of the book are *fantastic* and well justified though most of the examples are pure Java-specific. Latter sections of the book is more into Java centric, and thought of skimming few sections (disappointingly) but was compelled to continue reading. The book must titled "Clean Code (Java)". Though this book makes more sense for Java developers at the beginners and intermediate levels, I would definitely recommend the book to any .NET C# developers as well.

All in all, it was well worth a read! I got a clear picture of how developers end up with smelly code and how we can refine and "clean" it up.

/KP
Review: Clean Code by Robert C. Martin

[Gabriel Chartier · Rating 5 out of 5]

An opinionated collection of code standards that every developer should read.

If every developer read this with an open mind, took notes, and implemented even a few of the disciplines, we would all be better off. Clean code is incredibly hard to come by which is a shame because that just indicates how unprofessional the software industry really is. This stuff isn't hard, it just requires you to have the discipline to spend a few extra minutes writing a second or third draft of your code with a few things in mind. We need more developers to give a shit about things like this so that the codebases we work on can be more maintainable, readable, testable, and flexible.

It's not a perfect book. Most of the opinions are backed by sound reasoning, but some are dogmatic and overdone. Most are general enough to apply across languages, but some are Java-specific. I'm primarily a TypeScript/JavaScript developer so there were several chapters that I skipped due to the java-specific nature. The writing style is steeped in boomer and the illustrations were badly drawn and weird.

All of that aside, the things I took away from this book will be invaluable to my career, and invaluable to every codebase that I contribute from here forward.

[Rostislav Vatolin · Rating 5 out of 5]

To me this book is an extension of Martin Fowler’s “Refactoring”. As a Java developer I enjoyed it. It’s an easy read. I agree with everything, except “J1: Avoid Long Import Lists by Using Wildcards” and using less of final keyword (agree with Robert Simmons here more, he explained it in his “Hardcore Java” book). This book has some useful tips on how to avoid locks and other issues in multithreaded environment (I found it very useful).
In short, it is worth reading.

[Nick Hodges · Rating 4 out of 5]

I hate to say this, but I wasn't as impressed with this book as I thought I should have been, given its place in the pantheon of programming books.

The first half was excellent, but the second half left me a bit cold. It was too Java-y, and had -- dare I say it -- too much code in it.

However, I still list this as a must read for all developers.

[Alex Ott · Rating 3 out of 5]

Nothing new for experienced developer...
Too Java oriented in many places. Code Complete, 2ed is better from my point of view

[Kaaveh · Rating 5 out of 5]

فرقی نداره با چ زبانی و تو چ پلتفرمی کد بزنی. این کتاب از معدود کتاباییه ک هر پروگرمری باس بخونتش!

[JJ Khodadadi · Rating 4 out of 5]

خوندن این کتاب برای هر کسی که میخواد کد تمیز بنویسه سفارش میشه!! کدهاتون رو تمیز بنویسید :)

[Erika RS · Rating 3 out of 5]

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.

[Susan · Rating 4 out of 5]

This books makes me more aware of code quality, style and clean design. It introduces many areas to look out for when writing and commenting on code, and also includes some helpful principles on clean classes and clean systems. The book also includes a real example of the author's code and his attempt to iteratively refactor and clean it up to decouple the monolith class, to show how the theories from the previous chapters get applied.

Although I don't completely agree with all of the points the author raised (some are a bit too restrictive: functions should not have more than 3 arguments because then it's hard to uphold Single Responsibility Principle!), I can see where they come from. I give it 4 stars because it's very Java-heavy, and some example code can be improved further.

I think the most important takeaway from books like this is awareness. "Clean code always looks like it was written by someone who cares." I also liked the point about how programmers blame bad code on others: the requirements, deadlines, crazy schedule, stupid managers, intolerant customers, etc, but the fault is our own. Managers and customers may defend the schedule and requirements with passion, but it is OUR job to defend the code with equal passion.

[Craig Vermeer · Rating 5 out of 5]

This had lots of good, practical advice that spanned everything from naming to testing to concurrency. A lot of it was pretty Java centric, so I skimmed a few sections.

By far the best portions of the book were the ones where the author demonstrates -- step by step -- his process for writing code test-first, as well as refactoring.

If you get frustrated with either of the two at times, these parts of the book are *fantastic*, because you see that even someone who's been coding for 40+ years (like Uncle Bob has) writes messy code the first time! He just surrounds it with tests, and then little by little refines it and cleans it up. Awesome.

[Nick Skelton · Rating 5 out of 5]

Uncle Bob's book was given to me by a mate at work when I first started. I was introduced to the concept of code reviews and pull requests and told to expect a lot of comments on my code reviews to start with. I was then promptly given this book to read to minimise the pain. As a developer with ten years experience, I had seen so many of the things outlined by Uncle Bob and absolutely loved his remedies to them. I am now a convert to the idea of clean code and it has definitely made me a better developer... wait... a better person.