Re: detecting an undefined variable

[GrandFather]

Having read the conversation so far, maybe I can help shed some light on the issue you face. It seems your root concern is that you pick-and-mix code from other places and are concerned that variables picked up along the way may cause the resultant patchwork code to behave badly.

So the first thing is use strict; use warnings; are your friend. As a general thing Perl's scope rules (where an identifier refers to the same thing) are pretty sane. That in combination with strictures will pretty quickly weed out most badness. There are a couple of particular cases to think about:

• If you paste in a sub then none of the variables in the sub can "leak" into the surrounding code.
• If you paste in a block of code you can wrap it in {...} and guarantee that none of the variables can "leak" into surrounding code.
• If strictures throw up errors then most likely code somewhere wants Global variables. Global variables should be avoided where possible because they tend to contribute to hard to maintain code.
• Restrict variable to the smallest scope (set of {}) that makes sense.

[LloydRice]

In reply to Grandfather, yes, I pick-and-mix code from other places, but it is not a concern that such variables may cause the code to behave badly. But exactly the opposite. I WANT those variables, and having exactly their original purpose and value.

May I digress? I had been writing Fortran and C since they were respectively invented. I could not deal with C++. I started with Perl shortly after Llama came out (94, 95 ish). Friends tell me I should switch to Python. But I do not for exactly the above (C++) reason. I love it that Perl pretty much successfully hides the Object code. I will be 80 in a few weeks and I am not likely to relearn much else from here on out.

Thanks so much for all of your advice and concerns.

[GrandFather]

" I WANT those variables, and having exactly their original purpose and value."

In that case your concern should still be that the variables and patched in code behave badly. If you understand the original code well enough to transplant it then you should understand it well enough to put a nice wrapper around it so it doesn't interact badly with the rest of your code. The wrapper ensures you don't have undeclared variables so your original concern is moot. The trick of course is understanding the borrowed code well enough that it can thrive when transplanted.

Just the process of wrapping the transplanted code in a sub and providing a well defined set of parameters and results will drive understanding of what the borrowed code needs and what it does. Strictures of course help that process by pointing out issues early. If you are seriously concerned that the code behave as expected the next level is to write a test suite against the code.