Don't use "&" when calling a sub. It's old fashioned and if you don't know its meaning (I doubt you do), you probably shouldn't be using it.

Do *you* know what it does? If so, then your advice surprises me. What it does is prevent a Perl built-in from being called if your subroutine name happens to collide with the name of a Perl built-in. Why should anyone avoid that protection?

Quite the contrary, using & (and parentheses) to call your own subroutines is prudent style, especially if you don't name your subroutines with mixed case and don't care to memorize all of the current Perl keywords (some rather obscure) and predict possible future keywods (and monitor actual creation of new keywords and search all of your scripts when this happens and modify any that now require modification).

It can also be a nice style by visually distinguishing calls to built-ins from calls to user-defined subroutines (which can aid those reading the code by helping them figure out where to find more information on the named routine).

It is good advice to avoid using & without parens to call a subroutine. But that isn't what was done and you didn't even mention this problem. Also note that you should use & without parens with defined or to get a reference to a named subroutine.

Do *you* know what it does? If so, then your advice surprises me. What it does is prevent a Perl built-in from being called if your subroutine name happens to collide with the name of a Perl built-in. Why should anyone avoid that protection?

& disables prototypes and inlining. If used without parens and arguments, it implicitly passes @_. That alone should be a good reason for telling newbies to avoid using & when calling subs, or to always use parens. I think it's much better to simply say that & is not to be used unless you know why. Same goes for symbolic references, local (actually, package global variables in general), steak knifes and bicycles.

Calling a sub without the ampersand is faster. This doesn't matter of course, but perhaps this shows how the newer style is optimized.

Quoting a usenet post by tchrist:

(...) You can spot a an old, perl4ish, non-ORA, and/or non-lwallian book a league or seven away by its obsequious allegiance to an ampersand.

Quoting perlsub:

Not only does the "&" form make the argument list optional, it also disables any prototype checking on arguments you do provide. This is partly for historical reasons, and partly for having a convenient way to cheat if you know what you're doing. See Prototypes below.

(...)

(...) If you call it like an old-fashioned subroutine, then it behaves like an old-fashioned subroutine. (...)

Quoting perlstyle:

(...) Call your subroutines as if they were functions or list operators to avoid excessive ampersands and parentheses.

Also note that you should use & without parens with defined or to get a reference to a named subroutine.

I explicitly discussed *calling* subs with &. You do of course need it when you syntactically treat the sub as a variable.

Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }