Comments about oreilly The Art of Readable Code:

I understand that very often it is hard to give good guidelines.
Also they may differ for different programming languages.

At least the database related sample I find debatable from the perspective of the general solution approach; it could be both - simpler and more effective.

Still it gives unexperienced developers a sniff about where they could do better - ability to think and reflect assumed :-D ...

Comments about oreilly The Art of Readable Code:

A great handbook for starting programmers on how to write code that can be easily read and understood. Veteran programmers may find some of the information redundant to coding practices in the industry, but odds are there's at least a few things in here they haven't considered. A lot of emphasis is placed on being clear in your variable and method naming. Code examples are in different languages, but are clear in their meaning.

Comments about oreilly The Art of Readable Code:

"Code should be written to minimize the time it would take for someone else to understand it." - That code is easy to understand is the essence of this book. Personally, I find that I can usually look at the table of contents and see whether a book is interesting to me. Have a look for yourself! In relation to other reviews here, I found the format of this book good. No, there are not a lot of pictures or colours (nor should it be). However, the authors use comics to illustrate what they mean, "key ideas" (similiar to "tips" in the pragmatic series), and _very_good_ summaries at the end of each chapter. It feels like the authors have put a lot of effort into the structure of the book, not unlike the structure of how they propose code should be written.

The contents of the book actually overlaps somewhat with existing literature like Kent Beck's "Implementation patterns", Uncle Bob's "Clean Code", and "Code complete", but it shouldnt be compared to the latter as another reviewer did. This book is actually much narrower than all the others, as it does not cover good design principles, testing etc. Just as good code, this book does one thing - explain and reason about how to improve code for readability.

An interesting conflict is that meanwhile "clean code" is generally negative about needing to comment code, this book encourages to include "director commentary" (the stuff that goes through your head while coding) and "big picture comments" (that eases initial understanding of the code base).

I did not see where the authors recommend writing lots of static methods. However, solving a given software problem often needs you to solve another unrelated problem first (the authors use an example where some text is stripped and converted into an URL). These unrelated subproblems can be generalized and put into a utility library for reuse. I dont think it is such a bad idea. At work, we have lots of XML manipulation spread across components and meanwhile there is a utility library for reading XML contents, there is nothing for creating. Something like that could be generalized and reused with a clean interface instead of code that is similiar although not quite alike.

I think this book and clean code will get you a solid ground in writing readable and clean code.

Comments about oreilly The Art of Readable Code:

Naming part of the book is interesting, and I agree with a good part of the recommendations. But recommending to use static methods is against the testability of code.

Also, I would not recommend some uses of comments as presented. I like the approach of Clean Code, Thoughtworks Anthology to use small methods and to apply the Single Responsability Principle and Single Level of Abstraction Principle. If I should comment three blocks of code in a function, then I should use three sub-methods. These sub methods, given a proper name would remove the use of the comment.

The 2 stars is more a "I do not agree" than a "Not good". No judgement here, just a different point of view. I agree more with Clean Code point of view.

Comments about oreilly The Art of Readable Code:

As I also have Code Complete I'm forced to compare this book to it.

I would say that Code Complete covers almost everything presented in this book and lots more. Nevertheless this book goes deeper in everything than what is presented in Code Complete.

The presentation in the book was mostly extremely plain, only color in the pdf was in the covers and links. Only other "effect" was few cartoon images but I think they brought mainly style conflict and emphasized the plainness of the book.

For me the conclusion is that Code Complete is a better book.

Comments about oreilly The Art of Readable Code:

I've read the pre-release on Safari and from that alone I can give this book high praise and add that this is long overdue! I've ordered copies for our developers and interns, and this will be the technical book we read and discuss this year.

My only critique thus far would be their (albeit brief) treatment of Hungarian Notation in chapter 2 under the section "Attaching Extra Information To A Name" seems unfair. Rather than restate what Joel has already so eloquently stated, let me just provide a link to his 2005 article - which which would make a great introduction to this book - on making wrong code look wrong.

http://www.joelonsoftware.com/articles/Wrong.html

I understand that their statement about Hungarian notation is (likely) derived from textbook descriptions and current usage, but the original paper on Hungarian notation is much more similar to the general message of the book than they make it out to be.