Yeah, but that statement is a bit silly. Using all cap names
doesn't avoid collision with other barewords. Typical barewords
found in Perl programs are uppercase: file and directory handles.
The other major category of barewords are in titlecase: package
names. Barewords as in unquoted strings I only find in the
student books of the Perl courses of HP Education.
Avoiding collisions with subroutine names? Come again? You know
which subroutine names you are using, don't you? Besides, what if
you do use subroutines, aren't you in grave danger of colliding
with other subroutine names? No, of course not. It's not a problem
for the set of subroutines in a program, and won't suddenly be
a problem if you use lowercase constants.
Leaves us collisions with keywords. Well, you know which keywords
there are, so it's easy to avoid them. The only potential problem
you have is when you upgrade perl, new keywords might be introduced.
Of course, you already have a problem because subroutine names
can collide as well. But how common are new keywords in new
versions of Perl anyway? In the last couple of yours, new
keywords are our and lock, both
introduced in 5.005. But in 5.005, we also saw the birth
of INIT and in 5.6.0, CHECK was
introduced. So, using all caps is as likely to cause a collision
as to use all lowercase.
If you want to reduce the chance of collisions, you'd use
names starting with a lowercase letter, and having one or
more uppercase letters in them as well.
Abigail | [reply]
[d/l]
[select] |
| [reply] |
Yes, but I find constants even weirder when just using lowercase. I find it easier to maintain code if I stick to the usual sigils, uppercase FILEHANDLEs and lowercase sub_names. Using constant would somewhat spoil that scheme. Or maybe I'm just not flexible enough :)
| [reply] |