I would not be surprised if this book turned out to be one of O'Reilly's best sellers. This is definitely a keeper, and one to be kept close at hand until you learn all of its 500 or so pages.

This is one of the best written works I've seen in quite a while. The editing is actually quite good, with almost no obvious errors. The author clearly explains the reasoning behind each suggestion made, and injects subtle humor regularly. I appreciated the vim configurations which helped to create code in the suggested style, and for those who prefer emacs (and some others), those are covered as well. And to enforce the standards and style, there is a perltidy configuration, too.

Most programmers have their own standards and style of coding, sometimes even when everyone else in their shop is doing something completely different. It's often a fair amount of effort to change, just because of the ingrained habit. That's been my experience as I have changed styles to match various projects, teams, and employers. While you ultimately may not want to follow all of the recommendations, you should at least pay attention to the reasoning. For the most part, I have decided to change over to the author's recommendations - I say that because there are some minor inconsistencies that I don't like, even though the reasoning makes sense. Ultimately, there are different ways to look at any issue, and you have to make up your own mind about what is presented - which trade-offs do you want?

I want to make a fairly complete switch to the author's recommendations because I expect his guidelines will be widely adopted, and as a contractor, it will be easier to fit in if I am already comfortable with most of the code I'll be running into. It will also be useful for personal projects that become salable - you want good code so that you don't have to spend time cleaning it up before it can be sold. (One of the large organizations I worked for had an internal application that one of their vendors wanted to market to other customers, but the shop responsible for it spent over a year cleaning up the code before they could do so. This would not have happened if they had some reasonable and consistent standards in place in the first place.)

The organization of the material is reasonable, starting with general layout, naming conventions, variables, and working up to more advanced coding with error handling, objects, classes, and even debugging. Despite its size, this book could easily be handed out to all team members after writing "Coding Standards" in permanent marker on the cover. If something is not yet habit, it is fairly easy to find, and by running your code through the recommended perltidy configuration, you will at least catch any format/layout mistakes.

My code is already over 50% compliant with the author's guidelines to start with, mostly the good structure and readability items, with the non-compliant parts likely a habit thing picked up back when I didn't give much thought to such particulars. I am just glad that I was not tasked with researching and creating such a thorough and reasoned set of coding standards, and that all I had to do was get the book.