I know I don't need the % prototype, but it helps those who come after me know what the subroutine expects.

That's no reason to use a prototype. That's what comments are for. Perl's prototypes aren't really prototypes at all. It's a great irony that so many people use them under the impression that they are making their code more maintainable because using them without knowing exactly when it is OK to use them will do exactly the opposite.

Prototypes in Perl should be avoided in all but the rarest of cases. See Tom Christiansen's article on them.

-sauoq
"My two cents aren't worth a dime.";

So if Perl prototypes are so critically borked, and this was known in 1999 when Tom C wrote the article, why does my 5.8 perlsub documentation from 2002 imply they are a good thing?
Confusing signals, people ...

--
bowling trophy thieves, die!

So if Perl prototypes are so critically borked, and this was known in 1999 when Tom C wrote the article, why does my 5.8 perlsub documentation from 2002 imply they are a good thing?

Where does persub imply they are a good thing for general use? It seems pretty unbiased to me. It tells what they do and what they are good for. It goes so far as to tell the primary purpose for them:

. . . the intent of this feature is primarily to let you define subroutines that work like built-in functions . . .

I agree that the docs could be better in pointing out the hazards, but I don't think they are endorsing general use either.

Besides, I wouldn't go as far as to say they are "borked." They just aren't "prototypes" in the sense that people with experience in other languages generally think of prototypes. That's where the breakdown really occurs because, in other languages, prototypes aren't just good; they are often required. In Perl, what we call "prototyping" is a useful language feature and necessary for things like making inlinable constant subs (rare), subs that act like builtins (rarer), and creating new syntax (rarest.) The downside is that the feature was poorly named and, as a result, people end up slapping them on every sub they write.

-sauoq
"My two cents aren't worth a dime.";

I meant nit as in nitpick, which appears to have an etymology related to lice eggs. (Those little circles in the percent sign are a happy accident.)

I don't understand what you mean by it helps those who come after me know what the subroutine expects. If they're reading the code, why not read the very next line in the function to see exactly how you're dealing with parameters? If they're reading the documentation, you'll have to tell them what to expect anyway.

I'm all for not repeating myself. I just don't see what the function parameter adds.