Re^2: coding rules

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!

Comment on Re^2: coding rules

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