Warnings are generally there to reduce the risk of you getting yourself into coding trouble, and to let you know that you might be doing something that has unintended consequences. A best practice would be to write clean enough code that you don't trigger warnings. If you are getting a warning, you might want to look at your approach and see if there's something that can be done to clean it up.

Very occasionally you might be doing something intentionally that triggers a warning. In such cases there is the "no warnings qw/warnings list/;" pragma, which can be used to lexically shut off a particular warning. When doing so it is advisable to disable the specific warning in the smallest possible lexical scope so that you still gain the benefit of that warning being active everywhere else in your code.

But for the most part disabling warnings should not be used as a crutch enabling you to go on coding without bothering to learn "a better way." It's a little like the advice many give regarding symbolic references; just because they exist and you can use them doesn't mean that your situation is the special case that tips the "pros/cons" scale in favor of your using them. Nevertheless, Perl gives us symbolic refs so that those who have a true need can use them. Turning off a specific warning in a narrow scope is perfectly fine, provided it's not being done so that you can write buggy and unmaintainable code.

With that introduction, the required reading for selective warnings is perllexwarn -- a document that discusses lexical scoping for warnings and provides a tree of possible warnings.