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.
PBP: 024 Booleans
July 24th, 2014PBP: 023 Identifiers
July 21st, 2014This 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.
PBP: 022 Automated Layout
July 17th, 2014The 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. Read the rest of this entry »
PBP: 021 Lists
July 14th, 2014Lists 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. Read the rest of this entry »
PBP: 020 Ternaries
July 10th, 2014The 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.
Writing 2014-06-05
July 5th, 2014Writing 2014-06-04
July 5th, 2014Writing 2014-06-03
July 5th, 2014Writing 2014-06-02
July 5th, 2014PBP: 019 Assignments
July 3rd, 2014The PBP suggests breaking assignments much like it suggests breaking other operators; the assignment leads the broken line:
my $thingy = $stuff + $hard_things + $foo;