Clean Code: A Handbook of Agile Software Craftsmanship

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.

Read it with open mind,
I didn't agree with everything Author said,
But overall good lessons there.

The first few chapters of this book are thoughtful and compel the reader to take action with clear arguments for the benefits of improving code. The rest of the book dives into details that some readers may enjoy and others may want to skim.

Certainly a useful argument to write better code and improve code aggressively.

If you're a programming, this book is a must read

I am not a computer scientist or even software engineer, but I program quite a bit for my day job. This book had a little useful information to me (mostly in the first few chapters), but I just couldn't relate to the rest. I suggest you skip this unless you're a professional Java developer.