1) Place a semicolon after every statement.Agreed; if I come back to add another statement later, I don't want to have to look and see whether the formerly-last statement has a semicolon yet. Same reason applies when always following the last item in a list with a comma. (The inability to use that trailing comma is reason #853 why I hate PHP.)
2) Never place two statements on the same line.
Eh. In most cases, yes; but when I have two or more small statements that go together as a set, it's clearer to me if I put them together on one line. For instance, if setting a set of 3D coordinates:
Of course, the second one is a single statement with three effects. But can you really say it's okay and the first one is bad? To me, either one makes it very clear that the items are a set, and the statements are short enough that it saves space without getting overly dense.
3) Always start your elsif or else block on a new line.
Get thee behind me. I hate, hate, hate curly brackets on their own line, unless at the end of a complete block ( and that's only because I don't know where else to put it). I have no idea why I'd want to use up 8 lines on this ode to whitespace:
when I can do this:
I have more trouble seeing the flow in the first example than the second, and it takes up more space in my terminal. I know, this is one of those personal style things, so I'm not going to try to convert anyone else to the One True K&R Way. But please don't tell me the first example is better. It's not.
4) Always use a label on loops when using next, last and redo.
Bah. In the extremely unlikely event that I discover that a loop needs an inner loop I hadn't thought of (I've wrapped an existing loop inside a new one before, but I don't think I've ever needed to go the other way around), I'll notice these statements while I'm re-indenting. If my loop is so long that a next unless $something; can hide from me, it probably needs to be redone anyway. And really, thanks to Perl's map, grep, and hash lookups, nested loops are rare enough (in my work, anyway) that I'm not going to add some extra typing to all my loops because it might end up coming in handy for the one-in-a-thousand of them that are nested.
CamelCase is preferable over uppercase, unless it is an acronym. Never use all lowercase. Never use underscore.
Preferable for whom? I don't like any of them, honestly, so I tend to keep my variables to single words and acronyms as much as possible. I prefer the clarity of the underscore look, but hate typing shifted characters when I don't have to. CamelCase is ugly and gives me Java flashbacks. Stringing lowercasewordstogether isn't very legible, but least offensive to me. Sometimes I wish I could use a hyphen in variable names, as in Emacs.
9) Never use $_ or the invisible equivalent.
Bah again. Yes, I know $_ can bite you in certain circumstances. But consider the following:
Please don't tell me that the second one is better. It's more cluttered, so harder to read, and the extra variable introduces five more opportunities for typos -- seven if you count the need to include the =~ operator explicitly now. Avoiding $_ at all times because you fear stumbling across one of those odd circumstances where it's a problem (without recognizing it) is like wearing a steel helmet whenever you go outside because you're afraid of meteorites. $_ is one of Perl's best features. Use it without fear; just know how.
11) Always use if blocks, never postfix if statements as a one-liner.
So I shouldn't say:calculate_time($date) if defined $date;
? I'd probably reword that to say something like, "Don't use postfix modifiers after complex or multiple statements." I wouldn't do the following, because I'm not sure how the precedence would work or if they'd even compile:
13) Use unless and until as little as possible.
I don't see why. One of the beauties of Perl (intentional, I think) is the ability to write things similarly to the way you'd say them in your native language. If the process I'm thinking in my head is, "Do this unless the Found flag is set," then I don't see why this isn't the best way to code that:
All the other guidelines seem fine to me.