As I mentioned, there were a few stylistic guidelines that I don't adhere to; none of them strike me as flat-out wrong, but I've chosen to do things differently.
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".
