Perl is a malleable language. You can write programs in whichever creative, maintainable, obfuscated, or bizarre fashion you prefer. Good programmers write code that they want to maintain, but Perl won't decide for you what you consider maintainable.
Perl's parser understands Perl's builtins and operators. It uses sigils to identify variables and other punctuation to recognize function and method calls. Yet sometimes the parser has to guess what you mean, especially when you use a bareword--an identifier without a sigil or other syntactically significant punctuation.
Though the strict pragma (pragmas) rightly forbids ambiguous barewords, some barewords are acceptable.
Hash keys in Perl are usually not ambiguous because the parser can identify them as string keys; pinball in $games{pinball} is obviously a string.
Occasionally this interpretation is not what you want, especially when you intend to evaluate a builtin or a function to produce the hash key. To make these cases clear, pass arguments to the function or use parentheses, or prepend a unary plus to force the evaluation of the builtin:
Package names are also barewords. If your naming conventions rule that package names have initial capitals and functions do not, you'll rarely encounter naming collisions. Even still, Perl must determine how to parse Package->method. Does it mean "call a function named Package() and call method() on its return value?" or "Call a method named method() in the Package namespace?" The answer depends on the code you've already compiled.
Force the parser to treat Package as a package name by appending the package separator (::)Even among people who understand why this works, very few people do it. or make it a literal string:
The special named code blocks AUTOLOAD, BEGIN, CHECK, DESTROY, END, INIT, and UNITCHECK are barewords which declare functions without the sub builtin. You've seen this before (code_generation):
While you can declare AUTOLOAD() without using sub, few people do.
Constants declared with the constant pragma are usable as barewords:
These constants do not interpolate in double-quoted strings.
Constants are a special case of prototyped functions (prototypes). When you predeclare a function with a prototype, the parser will treat all subsequent uses of that bareword specially--and will warn about ambiguous parsing errors. All other drawbacks of prototypes still apply.
No matter how cautiously you code, barewords still produce ambiguous code. You can avoid the worst abuses, but you will encounter several types of barewords in legacy code.
Some old code may not take pains to quote the values of hash pairs:
When neither the Floyd() nor Annette() functions exist, Perl will interpret these barewords as strings. strict 'subs' will produce an error in this situation.
Code written without strict 'subs' may use bareword function names. Adding parentheses will make the code pass strictures. Use perl -MO=Deparse,-p (see perldoc B::Deparse) to discover how Perl parses them, then parenthesize accordingly.
Prior to lexical filehandles (lexical_filehandles), all file and directory handles used barewords. You can almost always safely rewrite this code to use lexical filehandles. Perl's parser recognizes the special exceptions of STDIN, STDOUT, and STDERR.
Finally, the second operand of the sort builtin can be the name of a function to use for sorting. While this is rarely ambiguous to the parser, it can confuse human readers. The alternative of providing a function reference in a scalar is little better:
The second option avoids the use of a bareword, but the result is longer. Unfortunately, Perl's parser does not understand the single-line version due to the special parsing of sort; you cannot use an arbitrary expression (such as taking a reference to a named function) where a block or a scalar might otherwise go.
In both cases, the way sort invokes the function and provides arguments can be confusing (see perldoc -f sort for the details). Where possible, consider using the block form of sort instead. If you must use either function form, add a comment about what you're doing and why.
Hey! The above document had some coding errors, which are explained below:
- Around line 3:
-
A non-empty Z<>
- Around line 67:
-
Deleting unknown formatting code N<>