>Michael Fowler sent the following bits through the ether:
>> Personally, I think FindBin is a bit of a sore thumb. Its name, the
>> capitalization of its variable names
>I suppose we could try and define some Perl Naming Conventions - ie
>instead of DumpCore() we should have dump_core().
Agreed completely. This was a complaint I heard at TPC: that the
core modules were inharmonious in this regard, and that they thus
needed homogenization. It's hard to back-fit changes, so it's more
important that naming conventions be followed when the module first
gets wrapped into the core.
Camel 3 (and many other things) reads:
=item *
While short identifiers like C<$gotit> are probably okay, use underscores
to separate words. It is generally much easier to read
C<$var_names_like_this> than C<$VarNamesLikeThis>, especially for
non-native speakers of English. Besides, the same rule works for
C<$VAR_NAMES_LIKE_THIS>.
Package names are sometimes an exception to this rule. Perl informally
reserves lowercase module names for pragmatic modules like C<integer>
and C<strict>. Other modules should begin with a capital letter and use
mixed case, but probably without underscores due to name-length
limitations of some primitive filesystems.
=item *
You may find it helpful to use letter case to indicate the scope or
nature of a variable. For example:
$ALL_CAPS_HERE # constants only (beware clashes with Perl vars!)
$Some_Caps_Here # package-wide global/static
$no_caps_here # function scope my() or local() variables
For various vague reasons, function and method names seem to
work best as all lowercase. For example, C<< $obj->as_string() >>.
You can use a leading underscore to indicate that a variable
or function should not be used outside the package that defined
it. (Perl does not enforce this; it's just a form of documentation.)
--tom
