Mabey you aren't using a variable, but I think this isn't in the spirit of what the poster wants.

The 15 year old, freshman programmer,
Stephen Rawls

Maybe it is, maybe it isn't, but it is the best way to do it. The only other things you can do are add lots of tests or turn off all warnings. Lots of tests can be clunky, and no warnings at all means you have to keep the code locked in the basement where nobody can see it. ;)

But, most of the complaints about the old way of turning off warnings aren't relevant to the new pragma. It _is_ bad to be messing with localized vars to control the compiler or interpreter. It got the job done, but I'm sure happy for the warnings pragma and filehandles as objects... it lets me throw local out of my box altogether.
--
Snazzy tagline here

warnings are a good thing. I'd never just turn them off to begin with. But saying that an experienced programmer is likely missing something because there is a warning is rather suspect. The argument works great for the general case, because at the level of a whole program there is a lot more room to miss something. But, if there is a reason not to turn off specific warnings for a short time, it isn't that there is still a "problem." For example, if you'll dealing with hashes, you'll get uninitialized errors in some types of things, but whether it's initialized might be besides the point. If it exists might really be what matters.

Adding extra code that isn't needed to get rid of the warning is at least as bad as turning off the warning where you know it isn't a problem, so judgement is required.

I think a good rule is, "if you fully understand why you're getting the warning, then it's your call if it should be on or off." If you don't know what the warning is, but just want it to shut up, then yeah, read the manual, fix the code, etc.
--
Snazzy tagline here

I respectfully disagree...

Just because you "know" why, and don't feel like updating your conditionals, etc -- imagine 3 months or more down the line someone else has to support the code. They will not "know" the same thing you do.

The more complete, easier to maintain method (IMO) is to update your conditionals...

if ($foo{'test'} eq 'bar') {
}

# Becomes
# exists could be defined depending on circumstances.
if ( (exists $foo{'test'}) && ($foo{'test'} eq 'bar') ) {
}
[download]

This code now makes it explicit to future maintainers that there is a possibility that the code could be querying non-existent data, and that this is an expected behavior (expected because the code supports it).

I would personally rather see the conditionals, etc updated rather than seeing warnings being flipped on and off throughout the code.

Plus, the questioner was obviously new to using hashes and was making a mistake with their use of them. So your answer to turn off the warnings would have resulted in the hiding of an error, the error that you "knew" was not there and "fully understood" the reason for.