Re: coding rules

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:

for my $f ( @filenames ) {
  open my $in, $f or die $!;
  print uc while <$in>;
  close $in;
}
[download]

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.

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:

use constant DEBUG => 0;
my $File_Scoped_Lexical = 1;
$main::globals_suck_bigtime = 2;
[download]

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.

the lowliest monk

Comment on Re: coding rules Select or Download Code

Replies are listed 'Best First'.
Re^2: coding rules by ihb (Deacon) on Jun 12, 2005 at 00:16 UTC
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. ... and once you change the package name you'll almost definately create a bug. This might not apply to you as you're mostly a script author, but as a module author this just isn't a good advice. Why should package variables be more cumbersome and less used that file-scoped lexicals? Btw, why do you feel a need to typographically distinguish file-scoped lexicals from package variables? During development I sometimes go from file-scoped lexical to package variable and back to file-scoped lexical again, and in my module I often don't care what nature the variable is since I inside the file usually just have one package. (If I have two packages I usually put them in different lexical scopes, and put any shared variable at file scope. Keeping track of those very few variables isn't hard, especially since they're the first thing you see when you open the file.) I'm interested in what made you choose this style with regards to package variables. `ihb` See perltoc if you don't know which perldoc to read!	[reply]
Re^3: coding rules by tlm (Prior) on Jun 12, 2005 at 13:28 UTC
I'm interested in what made you choose this style with regards to package variables. The same principle that motivates the entire thread: to make different things look different. Full qualification seems to me like the natural way to make package variables stand out as such. Package variables are the worst, because their scope transcends a single file. I'm less worried about package name changes (my editor can do search and replace fine) than about typos (e.g. assigning to `$Typo::foo`). If I were to drop this coding practice, this would be the reason. But, anyway, I already refer to all package variables, even those from modules I did not write, using fully qualified names, because I think it makes the code clearer. So this particular practice of mine is an extension of a more general one. the lowliest monk	[reply]
Re^4: coding rules by ihb (Deacon) on Aug 05, 2005 at 23:00 UTC
Package variables are the worst, because their scope transcends a single file. How are package variables worse than file-scoped lexicals? If it's because it allows people to mess with parts of your code that you didn't intend, then why use a package variable instead of a file-scoped lexical? (Yes, there are a few rare legitimate reasons.) If you have a legitimate reason for using it but it's not a part of the interface, is it bad because you feel a need to "protect" your variables from users? (If that's the case I guess regular subroutines are bad too.) If you have it like a package variable because it's a part of the interface, then it's not evil. Those are the cases I can think of where I'd use package variables in modules, and I can't figure out why you think package variable are "the worst". Can you elaborate? `ihb` See perltoc if you don't know which perldoc to read!	[reply]