note simonm 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. <p> 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: <ul> <li> Use two column indents rather than four. <li> Omit semicolon after the final statement in a block if it is an explicit or implicit return. <li> Cuddle elses and elsifs. (Add a blank line above if the else block forms a paragraph.) <li> When breaking lines for an assignment, put the equal sign after the variable name. <li> 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. <li> Always put semicolons at the end of a line, never on a line by itself. <li> It's OK to use implicit returns when a subroutine ends with delegation or calculation of the result. <li> Use two-part version numbers for portability, not three-part version strings. <li> 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. </ul> <p> 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". 477093 477093