in reply to Re^2: coding rules
in thread coding rules

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

Replies are listed 'Best First'.
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!