I like (and in fact follow) your rules for the most part. Like others, I detest camelCase, so I never use it when defining my own identifiers.
I like the rule that says that the larger the scope of a variable, the more descriptive its name should be. So, I may use $Input_Filename for a file-scoped lexical, but a mere $f in something like:
Hence I'm not crazy about the idea of prepending "this_" or "local_" to function-scoped lexicals. Since these happen to be, by far, the more numerous of my variables, I prefer to distinguish the few remaining variables in my code.for my $f ( @filenames ) { open my $in, $f or die $!; print uc while <$in>; close $in; }
There are three kinds of "broad scoped" variables that I try to distinguish typographically: constants (which, actually, are not variables at all, neither semantically nor implementation-wise), file-scoped lexicals, and package (aka global) variables. For constants I use all-caps; for file-scoped lexicals I capitalize the first letter of each underscore-separated word; for package variables, I use the fully qualified name, in lower case. Hence:
Yes, it is a pain to fully qualify package variables, but that's the point: their cumbersome nomenclature indicates that they should be used as little as possible.use constant DEBUG => 0; my $File_Scoped_Lexical = 1; $main::globals_suck_bigtime = 2;
the lowliest monk
In reply to Re: coding rules
by tlm
in thread coding rules
by punkish
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |