• Page 100, last non-code line: this line references "even()" but all of the earlier mentions said "odd()".
• Pge 308, first non-code line: "table-drive approach" =~ s/ve /ven /;

I can't find the Getopt::Clade on CPAN; am I looking in the wrong place?

Also, on page 151-152, I was disapointed not to find an example of GRT sorting; I know you mention it on page 164, but a roll-your-own example might help popularize this seemingly esoteric technique...

# Sort by SHA-512 digest of scripts
# (optimized with Gutman-Rosler packed default sort)
@sorted_scripts 
  = map { substr($_, 64) } 
    sort 
    map { sha512($_) . $_ } 
      @scripts;
[download]

Thanks for the errata. I've passed them on to O'Reilly.

Getopt::Clade will be on CPAN in August. Unfortunately, my planned release schedule had to be slipped slightly due to a series of family medical emergencies.

Regarding no GRT example: There were probably two dozen examples of useful-but-not-essential techniques that I had to leave out to keep the book to a "mere" 550 pages. GRT was one of those.

My sympathies on the medical front; best of luck there.

# PBP .perltidyrc file

-l=78   # Max line width is 78 cols
-i=4    # Indent level is 4 cols
-ci=4   # Continuation indent is 4 cols
-st     # Output to STDOUT
-se     # Errors to STDERR
-vt=2   # Maximal vertical tightness
-cti=0  # No extra indentation for closing brackets
-pt=1   # Medium parenthesis tightness
-bt=1   # Medium brace tightness
-sbt=1  # Medium square bracket tightness
-bbt=1  # Medium block brace tightness
-nsfs   # No space before semicolons
-nolq   # Don't outdent long quoted strings
-wbb="% + - * / x != == >= <= =~ < > | & **= += *= &= <<= &&= -= /= |=
+ >>= ||= .= %= ^= x="
        # Break before all operators
[download]

Any typos are my fault, and not TheDamian's. (Edit: And there are 3 fewer typos than there were, thanks Util!)

Well, the odd -wbb list is inherited from perltidy's docs, so that one's not mine or his :)

Edit: Applied update to -wbb pointed out in Re: PBP's .perltidyrc file, was Re: Perl Best Practices. I wonder why !~ was removed?

Previous -wbb value:

-wbb="% + - * / x != == >= <= =~ !~ < > | & >= < = **= += *= &= <<= &&
+= -= /= |= >>= ||= .= %= ^= x="
[download]

perltidy now comes with option -pbp, --perl-best-practices

    -l=78 -i=4 -ci=4 -st -se -vt=2 -cti=0 -pt=1 -bt=1 -sbt=1 -bbt=1 -n
+sfs -nolq
    -wbb="% + - * / x != == >= <= =~ !~ < > | & = 
          **= += *= &= <<= &&= -= /= |= >>= ||= //= .= %= ^= x="
[download]

to know where to place the .perltidyrc file enter perltidy -dpro as reslut you'll get where perltidy is looking to find the config file. if one is found, you'll get the contents.

The errata corrects -wbb to: -wbb="% + - * / x != == >= <= =~ < > | & **= += *= &= <<= &&= -= /= |= >>= ||= .= %= ^= x="

-lt , line-up-parantheses is needed for -vt to have effect.

For amusement value only, here's a list of things I'd do differently that I noticed while reading through today, mostly from the first few chapters:

• Use two column indents rather than four.
• Omit semicolon after the final statement in a block if it is an explicit or implicit return.
• Cuddle elses and elsifs. (Add a blank line above if the else block forms a paragraph.)
• When breaking lines for an assignment, put the equal sign after the variable name.
• When breaking lines in a ternary expression, place the colon under the question mark for simple ternaries, or at the end of each line for cascading ternaries.
• Always put semicolons at the end of a line, never on a line by itself.
• It's OK to use implicit returns when a subroutine ends with delegation or calculation of the result.
• Use two-part version numbers for portability, not three-part version strings.
• Don't use a hash reference to hold named argument pairs when a regular list of pairs will do; getting an odd-number error at compile time rather than run-time isn't worth the extra punctuation this induces.

For the more contentious suggestions, Damian does a good job of laying out the various pro and con arguments, so it's easy to see how a development team could use this this text as the basis of their style discussions and end up with a document that says "use the PBP style except for the following 5-10% set of local differences".

These diffs are about the same we used to have in our coding guidelines in pre-PBP times. We abandoned them in favour of PBP.

The cuddled else/elsifs and 2-column indentation surely give you a more dense code - you see more "at a glance". But whether it is increasing age or increasing display resolution (increasing dpi as display sizes in notebooks remain quite the same) or both: believe me, having dense perl code on 140dpi+ with 6x13 font and folding on gives you more code "at a glance" you probably can handle.

What we have learned from PBP is, that it's not perfect. Contextual::Return has its problems with other recommended modules. I'm also missing a clear statement from the Damian about how future-proof the usage of Class::Std really is (in the light of it's flawed maintenance and in light of Moose). Never got any answer to that.

But other than that, we also have learned, that adhering to some guideline in PBP - even if you do not agree with it - is often the better choice, because the odds you being right and PBP being right are in favour of PBP and, as other people might have thought of other guidelines of their own to be superior to those of PBP, you again end up with a bunch of homebrew codebases.

Therefore, using Perl::Critic/perlcritic with defaults on -3, trying -2 on own code.

Bye
 PetaMem     All Perl:   MT, NLP, NLU

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! ;)

my $x = ( 1, 2, 3 ); my ($y) = ( 1, 2, 3 ); say $x; say $y; ... gives different results for the two styles if more than one thing is passed. So I'd stick with my ($x) = ...

Much of the Objects chapter is based on using Damian's Class::Std

While this may be an oversight, it could also be intentional as the book doesn't talk about threads at all.

xdg presents a mechanism whereby thread-safety can be introduced into an inside-out object model, and I have successfully used it in Math::Random::MT::Auto. Hopefully, TheDamian will incorporate xdg's concept into a future release of Class::Std.

One minor annoyance is that the suggested .pertidyrc file is not included in the source packet from O'Reilly.

Also, the -wbb option in the .pertidyrc looks a bit... odd. >= is there twice, as is <, unless I'm reading it wrong.

Ah, looking at the perltidy perldocs, looks like this is just an artifact of copying the perldoc's "break after" list into the "break before" list. So it's an inherited bug, if it's a bug...

In fact, I haven't been programming in Perl for a few years (I've been making lots of Perl scripts and fixes on existing Perl code as part of my sysadmin job, though). However, as I was discovering things like insideout objects and modules like Class::Std, I felt I needed to spend more time with Perl related stuff again (as in my old days of CPAN Testers), specially OO programming and testing.

By the way, don't forget to give a try to Perl-Critic, which implements many of the book guidelines. There's also an online version.

Regarding OO programming, be sure to also have a look at Moose.

The page seems to be actively maintained, and is now at rev 43.