Barewords

Perl is a malleable language. We can write programs in whatever creative, maintainable, obfuscated, or bizarre fashion we prefer. Good programmers write code that they want to maintain, but Perl won’t decide for us what we consider maintainable.

Perl isn’t perfect. Some features are difficult to use correctly. Others seem great but don’t work all that well. Some have strange edge cases. Knowing what to avoid in Perl—and when to avoid it—will help us write robust code that survives the twin tests of time and real users.

The barewords

Perl’s parser understands Perl’s built-ins 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 we mean, especially when we use a bareword—an identifier without a sigil or other syntactically significant punctuation.

Good uses of barewords

Though the strict pragma rightly forbids ambiguous barewords, some barewords are acceptable.

Hash keys

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 isn’t what we want, especially when we intend to evaluate a built-in or a function to produce the hash key. To make these cases clear, pass arguments to the function, use parentheses, or prepend a unary plus to force the evaluation of the built-in: