|
|
| There's more than one way to do things | |
| PerlMonks |
Re: Detecting scoping/namespace conflictsby stephen (Priest) |
| on Apr 03, 2002 at 17:10 UTC ( [id://156459]=note: print w/replies, xml ) | Need Help?? |
This is an archived low-energy page for bots and other anonmyous visitors. Please sign up if you are a human and want to interact.
I'll start with a brief discussion of my and local. However, the best way of dealing with this situation is to pull out the $localdata assignment into a subroutine. See the end of this note for a discussion of that. Good: use 'my' not 'local'Use my not local. local is used primarily for making a local-scope copy of a global variable; for example: prints out: my, on the other hand, always creates a new lexically-scoped variable that is only visible in the enclosing block or file. Use my for all of the variables that you yourself create. So, to modify your code:
Note: code untested Better: Refactor To SubroutineProblem is, $usefuldata serves no purpose here except as a placeholder. Nobody is incrementing it; nobody is altering it. It's either 1 or 2. (I know this is a simplified case, but the point still holds no matter how complex the logic.) It's far better from your code's standpoint to pull out the code that calculates $usefuldata into its own subroutine.
Note: Code untested An advantage to this is that you've eliminated $usefuldata entirely, and never need to wonder if somehow some other bit of code might have altered it. Everything having to do with $usefuldata is in one place. Gets off soapbox Update: Looking back, I'm not quite sure if you intended '1' to be the default case, or if the other $usefuldata was completely unrelated. This note assumes that you intended '1' to be inserted if your 'if' statement was false. In any case, replacing the variable assignment with a subroutine will solve the problem, because redefining a subroutine will cause a warning under '-w' anyway. stephen
In Section
Seekers of Perl Wisdom
|
|
||||||||||||||||||||||||