Essential reading for anyone who writes code - read it, use it as a reference, use it in your code reviews, in your pairing exercises, and made your code simple and expressive.

It has taken me a while to pick up this book, as I was already familiar with many of the concepts and the content from the beginning of my career as a software engineer, when I was really focused on improving the quality of my code and the productivity of my team. After I've moved into management, it's meant that every once in a while I need to work harder to restore my motivation and energy when it comes to interacting with code, because I just don't do this on a regular basis, and this book did the trick for me. So my recommendation is this: read this book when you are 2-3 years into your career as an engineer so you can visualise the consequences of these code smells, read it when you need a refreshing dose of motivation, and use it as advice when in doubt, it will serve you well.

It's not heavy in terms of too much code or too difficult code, it strikes that perfect Goldilocks balance of insightfulness and crispness. All statements are supported by examples and worst case scenarios, and some are intuitive (readability), some are more about thinking 2-3 steps ahead (extendability or maintenance). Let me tell you about some notes I took:
- Consistent indentation style was one of the most statistically significant indicators of low bug density;
- The indent level of a function should not be greater than one or two;
- The number of arguments in a function should not be greater than three;
- If you must encode either the interface or implementation, go for the implementation - it will pollute less of your code;
- Write for programmers: use CS terms, algorithm names, math terms and patterns;
- Separate solution and problem domain concepts based on level of abstraction;
- Make the code read top-down like a newspaper article;
- Functions should either do something or answer something, not both;
- Separate exception handling from logic blocks.

Combines inportant to know information. There is a lot of iteration over things, especially at the end of the book.

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.

A great read and I think it will be an even better re-read in the future. It is essential that each line of code, each variable name and each module layout receive the amount of attention required in order to deliver the lowest maintenance burden. This book drives home that message and then demonstrates the key techniques and heuristics that should be applied to code at review time. Essential reading

Must read for any programmer. The epic refactors would have worked better as screencasts but were still useful. I found myself nodding in agreement a lot thinking "yep I know this" but I am applying it all much better now. It put me in a really good state of mind.

Also, so glad I don't use java anymore.

I was lent this book over a year ago by my work, but for one reason or another, I’ve never quite got round to reading it (I blame Brandon Sanderson!). But having now read it, I do wish I’d got around to reading it before.

Read now, the book for me reinforced a lot of the things that I’ve learnt over the last year, as well as introducing a few new ideas, but if I’d read it a year ago I think I would have appreciated the things I was learning a lot more.

The book introduces many ideas for practices that we, as professional developers, should be following to ensure our code remains clean. Just because it works doesn’t mean it’s the best it can be, and in order to maintain the code for future years and future developers, we need to try our best to keep the code clean so that it’s more future-proofed, and also less likely to contain bugs.

Reading through the book brought to mind so much code that I’ve worked on in the past, both worked on by myself and by developers from the past, and made me think of habits that I’m guilty of that I’m going to try my hardest to change.

The only negative for me in this book was that the code examples were written in Java which I’m not familiar with – obviously it’s not too hard to pick up the meaning of the code, but I think I would have been happier with examples written in C# instead – and as I would recommend this book to any new programmer, it could be more off-putting for them. But I’d still recommend it anyway!

Posted on: http://emmaloui.se/2018/09/19/robert-c-martin-clean-code/

Started strong, then got tedious. Mostly just showing its age with case studies that felt super antiquated.

Must read book for intermediate level programmers

This book ages well. Yes, lots of Java examples, but still, great and concise explanation of what constitutes 'clean code'. Required reading for anyone serious about software development. I don't know what kept me from reading this until now! :-)