I'm not done with the book yet, but the style chapter in particular was a bit like instructions on "how to program like Damian." I guess there's simply no way to cover all stylistic options, and so Damian's choice to present a single, self-consistent style (his own) is understandable. I just wish there'd been more detail in his reasoning. In a few cases, he dismisses alternatives and explains his own choice in a very facile way.

Time and space restrictions explain that a bit, but even within the bounds of his own recommended style, I wanted to see more exploration of the inherent tensions within his style. For example, his preference for a 4-space indent, non-abbreviated variable names, and very clearly spelled-out subroutine names is slightly at odds with his line length recommendations.

Similarly, many of the later style rules are consequences of earlier ones. This is fine, and expected, but I wish it was explicitly stated. For example, the choice of K&R braces dictates the continued statement style (e.g., starting continued assignment lines with "=") and the other rules that are meant to disambiguate an indented line from a new scope.

Overall all, though, the introduction does an excellent job of explaining how to make the most of the style section: even if you disagree with a style guideline, just use it as a means to explore the reasoning behind your own style choice in that area.

There's one case that (IIRC) he didn't cover, however, when it comes to changing your own style. I have a personal, totally stupid and arbitrary habit of using parens with single-variable "my" statements *only* when I'm pulling off @_ args in a subroutine. (Everywhere else I just do "my $var") I'd like to stop doing it, because it's pointless and inconsistent, but then I'm faced with the problem that all of my new code would suddenly be inconsistent with my old code. And since the habit is not really harmful, I can't bring myself to break the consistency of my own code.

I imagine this applies to anyone contemplating a style change. So how, do you do it? Do you go back and update all your old code to fit the new style? Or do you just grit your teeth and move forward? Anal-retentive programmers need help in this area! ;)