Laufeyjarson writes…

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…)