I bookmarked a Slashdot comment (!) a few months ago that I thought raised some points that are mostly worthy of consideration.

Worthy of consideration, certainly, and many of them I quite agree with. I do think, however, that some of them are a bit misguided. I'm not convinced that $Mixed_Case_Globals, for example, are a great idea. Here are some more of my reservations...

His point 6, about blocks, I tend to disagree with; to me, that's redundant and wastes vertical space, resulting in the need to scroll more than is really necessary in order to see all of a function or block; this can really impede the reader's ability to follow the code in some cases, because when a block goes past a screenful it's *harder* to see where it starts and ends, not easier. If you pull up the braces inside that block onto their respective previous lines and let the indentation speak for itself, you can see more (if not the whole thing) at once. The indentation makes it visually clear where blocks end even if your text editor _doesn't_ do brace matching (which it does if it's not fundamentally lame). But if you put every brace on its own line, you can almost double the length of the function, in terms of the number of lines.

Point 11, about map, depends greatly on the background of your programmers. If you expect the code to be maintained by someone coming from a background in languages such as Java, it's probably good advice, but if the person doing code maintenance can be expected to have a couple of years' background in Perl or lisp, this concern goes away entirely. In some cases map adds significant clarity (assuming you understand lists).

I absolutely disagree about unless. It may not be common in other computer languages, but it's a very straightforward cognate for the English word "unless" and means exactly what you would think it would mean.

Using an explicit main() is completely pointless unless your main goal is to confuse C programmers about what language they're reading. (OTOH, he suggests putting an explicit exit before your post-defined subroutines, which is good practice IMO.)

Regarding one-letter variables: the point is valid, but his stance is IMO a bit hard-nosed. I like to use a one-letter variable when a given script or function really has one main object that it keeps working with a lot -- such as the record object that a function in a DBI script is working with, or the one WWW::Mechanize object that a web automation script is using every line or two. However, it is certainly true that overuse of short variable names is to be reserved for the Obfuscated Code section.

Point 18, about minimizing implicit pronouns, is one of the worst, most extremely misguided pieces of Perl style advice EVER. Cluttering the program with a couple of hundred stupid unnecessary extra variables that only hang around for a couple of lines does NOT make it more clear.

I agree with 19 in principle, theoretically, but I'm guilty of violating it without remorse with alarming regularity, usually when the scalar is either an index into the array or the iterator in a foreach over the keys of the hash in question.

Number 22 I also tend to disagree with: in many cases all it does is add extra lines, pushing more of the function off to the next screenful.

Number 28 reminds me of COBOL. Either write POD or don't, but this style suggestion is silly either way.

Number 29 seems to have forgotten that we have __END__ for this purpose.

OTOH, suggestion 14 (about having a routine that logs debug messages) is something I consider to be Very Good Style that is often missed, and many of the other suggestions are quite good too. It's definitely worth looking at and considering -- just don't take it as some kind of definitive authority; many of the points it makes seem geared more toward verbosity and C-like-ness than clarity.