Laufeyjarson writes…

The PBP suggests naming for hashes and arrays; hashes in the singular, and arrays in the plural. (more…)

The PBP suggests suffixing reference variables with _ref.  The book notes in a footnote that this is the only type of “Hungarian notation” suggested in the book.  That’s good, because Hungarian notation is a bad idea. (more…)

The PBP suggests that boolean variables and subroutines should get special naming consideration, and be named in ways that read well.  That may involve giving them names like “is_whatever” or “has_whaterver” or “can_whatever”, so that they make contextual sense.

(more…)

This section of the PBP is a long one, and goes into great detail about how to think about naming important parts of your programs.  It covers explicitly modules/namespaces, variables (several types of them), and functions.

I thought, at first glance, it was way too picky and specific, but the more I read it, the more I liked it.

(more…)

The Best Practice is to get a tool to do the work for you; it’ll be regular, and not spend your time doing it.

My only concern is that Mr. Conway says, “You can take ugly code like this and turn it into something readable.” where the “readable” code isn’t, to my mind, that much better.  Spaces around the parens and an extra blank line do not readable code make. (more…)

Lists need to be formatted to be readable.  The suggestion is to always use parenthesis, indent after a parenthesis, and line things in columns, all with trailing commas.

The book provides clear examples, which I won’t duplicate here. (more…)

The book talks about how confusing the ternary operator can be and how much of a mess it can make.  I’m almost surprised it doesn’t say, “Don’t use it.”

It suggests columns instead, with the condition, then the positive result.

(more…)

The  PBP suggests breaking assignments much like it suggests breaking other operators; the assignment leads the broken line:

my $thingy

= $stuff + $hard_things + $foo;

(more…)

This Practice is to break long expressions at lower-possible operators.  It actually says “the lowest possible precedence”.  At a glance, this sounds like a fine idea, and it, in general, is.  The reason given is pretty solid, that you can easily confuse people about precedence by splitting things apart.  This will be even more important on operators people may not be familiar with the precedence of.  (Quiz: Which is higher precedence “&&” or “and”?  Which is higher precedence, “~” or “^”?)

(more…)