Clean Code: A Handbook of Agile Software Craftsmanship

3.5 stars. I'm rounding up.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 been programming about 17 years and consider myself above average programmer. Yet, this book made me feel like I'm actually horrible coder. I've always gotten my tasks done but I didn't pay attention on refactoring to clean up the code. I'm already behind and got a demo coming up in few days. As I'm reading my guilty verdicts on all his 'bad code' examples, it inspire me to care about 'coding' yet again. It can be fun and it's not all about getting the job done. What's sad about the reality is that 'bad code' will continually increase over time because people don't realize what 'bad code' can do in the long run.Every programmer regardless of experience should read this book. Thanks!

Stay far away from this book of you are not an OOP programmer. All examples are in Java but most C++ programmers should be able to mentally translate the ideas. There is also too much focus on Java specific tooling. While there are some good points this book makes, it disregards many good programming techniques used in standard imperative languages without objects. It completely disregards functional languages and given gives some terrible advice when it comes to writing good code in a functional style. Overall it's pretty good up to about chapter 7. After that it's pretty much downhill.

Stay away from this book. It's a one person ramble about his preferences in coding. Plus he turns everything into a moral issue about being a “professional”. You are a professional if you earn money with the craft, period. This is what “profession” means. The rest are dogmas of Bob's cult, akin to Pythagoreans abstaining eating beans. Go to his GitHub page and see for yourself if you like his “clean code”. I don't.

3.5 stars. I'm rounding up.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.

This book has some great insight into how to create better code. The examples seem to be in Java but I think the concepts translate to most OO languages.

Good book and would buy again.

TL;DR: even if it is not 100% correct -- few are -- do read this book. It's a really good one.I've been in the industry for 22+ years, but just started to reread this book. I consider it to be one of the top books _any_ software engineer, developer etc. should definitely read.Now, I disagree with some of things strongly. Uncle Bob is quite biased towards OOP, and in general issues presentedare more complex and I'd claim that the only rule in software engineering is "it depends". In general my biggest complaint is that almost all of the rules I see anyone present come with a cost, with Clean Code it sounds like they are free. Eg. I really, really like simple, short functions/methods that do only one thing, but there is a cost of adding extra levels of abstraction. Even though I do prefer that over hundreds of thousands of lines of code in one method, it doesn't come as free (even though benefits far outweighs costs, given proper execution).The other example, just to mention an example, is on naming variables. In general I agree that long, good names are much better than short cryptic ones, but for short expressions like one-line transformations are often _easier_ to read if variables are short, and their scope is limited to that one line. As an example, any experienced Python developer would immediately recognize `squares = [ n**2 for n in numbers if even(n) and n > 10]` while using longer names would just make general form (where var names don't matter). Many guides nowadays describe this principle as "variable name length should be in relation to scope of the variable" which is a good rule, though I believe even that has exceptions.But having said that, I'd claim things would be in much, much better condition in software industry if people read this book. And definitely he has much more impressive track record than me, so I'm ready to accept that while I disagree with some of the things, I could very well be wrong (and still blind to it). SOLID principles are really good to understand, and the first one of those applies to _everything_, even if you use functional programming paradigm. Same goes for comments; comments are eventual lies, and developer should restrict IMO those to explaining _why_, not _what_.I read the book first time when I had been 5+ years in the industry or so, and it definitely made me a better developer. And while I now see rationale behind the rules in the book a bit lacking given complexity and variance in common problems developers face (mainly every solution has a cost), I still consider the book one of the best ones. Just get it and read it.

As part of our learning activities, we learn quite a few programming languages. We also learn designs, patterns, good coding practices, and many more. We don't usually spend time to learn how to write a good, readable code. The relevance of this book is enormous. Not just the programmers should read it, the education providers should also read it. In fact, the education providers should plan to include this in their curriculum associated with every programming languages.I started reading this book and finished it in almost three consecutive sittings. That way, the book is well structured, and the topics are well sequenced. The author cautioned at the beginning of the book that it is not for the armchair readers. The reader should spend adequate effort to read through the code examples, think through those, and try out some of those through self scribbling. This is indeed necessary for the coders. This is also necessary for the instructors of coding, or programming languages. I chose to skim through the examples with just enough thinking while paying attention to every detail of the English text. Such speed reading worked for me too. Such reading technique should work for all who are not into direct coding today, but was a programmer once upon a time, and spends a lot of time in conversing with the programmers nowadays.Coming back to the content of the book - this was quite informative and thought provoking. I read it fully and tried to jot down my takeaways from this book reading. I have got six of them.I learned the general rules for commenting, and summarized those in four points. I learned the general rules for code formatting, and summarized those in four points. I learned the general practice of code size - for a significant system, for a code file, for a typical function. I learned the general rules of organizing concepts and variables, and summarized those in five points. In fact, the definition of concepts was itself was a new learning for me. I learned the three laws of test driven development, rather I re-learned those once more while reading this book. Finally, I jotted down the final takeaway - leave the code cleaner than what you had started with.The book is full of good references, in fact at the end of every chapter. I tried to summarize the list of further readings, and I got another five book titles listed in my to-read list. I read it on my Kindle device, and on my desktop using Amazon Cloud Reader - the formatting was good.As coders, we all have the responsibility to leave the code cleaner than what we start with. As code reviewers, we all have the responsibility to comment on the cleanliness of the codes. As the supervisor or manager of coders, we all have the responsibility to communicate the importance of clean coding and to encourage coders towards clean coding. I will recommend to all these group of people to read this book, and practice the clean coding techniques described here.Good work indeed!

As CTO of a software company I co-founded, I'm not only looking for books that help me improve individually, but also books that the whole development team – from developers to architects – may find useful. Robert C. Martin’s Clean Code does both, and, like the good code described therein, it’s well written, clear, and easy to read. Martin includes many helpful examples and his suggestions are applicable to any programming language.Ideally, each developer takes charge of their own education and is constantly improving their skillset, an aspect that Martin covers in The Clean Coder. I view it as an important part of my job to help my team improve. To do so, I distill a lot of written material down to actionable components and provide that to my development team. Concepts from Clean Code have become very helpful guides for them. Below are a few of my favorite takeaways.The first is what Martin calls The Boy Scout Rule: “Leave the campground a little cleaner than you found it.” It’s a great concept, not only because it's simple to follow, but also because it has broad applicability and can be used on any project. Essentially, when a team member works on a piece of code, they should aim to improve it somehow by the time their task is finished. A few examples of this among many are: fixing an unclear variable name, breaking up a large function into smaller functions, or cleaning up a conditional for improved clarity. With everyone on the team doing this, the code improves over time and everyone feels responsible for the code whether they wrote it personally or not. Even if something can’t be addressed immediately, developers are encouraged to log the issues they see.Another of my favorite takeaways is the Three Laws of TDD, a concept I was able to quickly roll out to the team as a framework to follow for how TDD should be conducted on a project. This virtually ensures that all of your product code has test coverage. It also helps make most of your code SOLID (https://en.wikipedia.org/wiki/SOLID_%28object-oriented_design%29), since code that is built in this fashion is structured with SOLID concepts in mind. This is a must for effective testing.Finally, the topics of proper identifier names and commenting really resonated with me and my team. In our company, we tend to “adopt” existing codebases – projects that have already been started by other developers whose code is of widely varying quality. If we're lucky, it's structured well and demonstrates best practices and approaches in how it's constructed. Unfortunately, the code is sloppy at times and requires some TLC to get it in shape. A part of that process is understanding what the existing application does. As Clean Code correctly outlines, many comments are superfluous or even plain wrong and misleading. As a team, we don’t blindly trust the accuracy of existing comments and instead go right to the application’s code to determine what it does. This is where proper naming comes into play. With good names, the code reads like comments or as a narrative of what the application does, nullifying most needs for additional commenting. Simply put, the code comments itself. We also use refactoring tools to improve names and clean up comments as we go. Of course, by doing so, we’re also applying the Boy Scout Rule.Overall, Clean Code is a wonderful book with much useful and immediately-applicable information for developers of all levels. If you're looking for a book that will help make you a better developer, this will.

Decent principles, but a lot of the authors advice assumes that you're working in java. He doesn't explain the tradeoffs so if you're working in a different language this probably isn't the book for you.

Writing clean code is tough, but this book makes it clearer.

As design professional (of too many years now) I found my old scales too difficult to read any longer (mainly from use). These are great replacements. I would have given them a better rating, but they are the same basic design as all others I've ever used. They're newer, therefore, better.

These will make doing drafting drawings easy

This set has both architect's (1/4" 3/8" etc.) and engineers (10, 20, etc.) scales, plus a standard ruler. it is laser etched black anodized aluminum. it should last several years, but the anodized coating may rub off over time. the ruler also has a conversion scale on the back which converts fractions of an inch into mm. So far so good - i really like this set. You may wish to separately order protective cases for it. it does have sharp corners, though.

Very pleased with these. The quality is evident - these are not cheap plastic that can break. They have held up very well and are easy to use. Very clear markings and precise

These drafting rulers are worth the buck . . .metric scale yeessss.

Great book

I recently read Clean Code: A Handbook of Agile Software Craftsmanship and while I did enjoy it, I will say that some of the topics covered seemed like common sense to me. However, I have been coding for a while now and have had some great instructors, so it's possible that my prior knowledge and experience contributed to this. That being said, if you are new to coding or are looking to improve your software craftsmanship, I would highly recommend this book. It covers a wide range of topics in a clear and concise manner and provides valuable insights and best practices for writing clean, effective code. Overall, I think Clean Code is a great resource for anyone looking to elevate their coding skills.

Good book but certain advice applies only to Java and isn’t applicable