Should we avoid including warnings for the full program?

Question

I subscribed to [e-mail] There was a discussion, and the guy suggested you not to use

 #!/usr/bin/perl -w 

This will turn on a warning for the entire program. He said:

Please do not use -w in hashbang, it causes warnings everywhere, even if the modules did not need warnings. You will receive strange error messages if you leave this. Instead, just type “use warnings” at the top of the code and everything will be fine. :)

It activates warnings for code that you are not writing.

It is a very good idea to include warnings for all code that you write yourself. However, if you enable it for code written by authors who do not want warnings or for old modules, then you will receive meaningless messages that you cannot fix.

I said: "So you want to say that we should use warnings to use only some parts of the code.

He replied: Yes, specifically: only the code that you wrote yourself.

instead, you should use the warnings pragma in code that you did not write yourself for the complete program.

---

I used to write -w to shebang so that I can enable warnings for the entire program. But after this discussion, I am confused whether I should follow this guy or not. He is right? Should we avoid including warnings for the full program?

I usually follow

 #!/usr/bin/perl use strict; use warnings; #now start actual coding from here #............................... #............................... 

Answer 1

You quite accurately described the situation. -w includes warnings around the world (in all modules, unless they specifically disable them lexically). use warnings behaves lexically without affecting what happens in other modules.

Saying this, I do not see in it what is better. It really is a question of what kind of behavior you want. We would not say that foreach better than while without knowing the context of the statement. If you want warning behavior to be global, do it. If you want to enable warnings in a way that does not affect external modules, do this.

Warnings, in my opinion, are a development and debugging tool. I try to always program with 'on' warnings (in my own code). Regardless of whether I am deploying production code with warnings enabled, this is a completely different story. There are many factors that contribute to deciding whether to include warnings in production code. Naturally, the goal is programming without warning. Therefore, if warnings are included in the production code, and one slips, this should not happen if we have completed our work. But if someone slips through, will this information be useful to someone or not? And will the utility outweigh the added noise and potential risks of disclosing program information to unknown end users?

Regarding the topic of writing code without warning: Yes, that should always be the goal. However, there are many warnings. my @list = qw/ Just another Perl hacker, /; will cause a warning. This warning is intended to help me understand that I may have made a mistake (inserting a comma in qw // list). But, as many know, this phrase ends with a comma. A more important question is whether I really intended to make a list of words, not a single line. So let's say that I need a list of words, and one word legitimately needs a comma at the end of the word. In this case, the warning is not serious. I have two options. One, say my ( @list ) = ( 'Just', 'another', 'Perl', 'hacker,' ); , or two, say my ( @list ) = do{ no warnings 'qw'; qw/Just another Perl hacker,/; }; my ( @list ) = do{ no warnings 'qw'; qw/Just another Perl hacker,/; }; . They print a lot, and in this far-fetched example, it's probably best to just bite the bullet and use the first option. But this does not mean that the second option is a mistake, and there can be many less far-fetched examples of where a warning is undesirable.

Now let's look at a situation where it might be useful to trigger a warning in another module: you tore your hair for why you are not getting the expected results from the XYZ module. You can transfer your code using print statements, you could reset your data structure, you could plunge into the Perl debugger ... but what is wrong with the inclusion of warnings around the world, if you see something for only one run you do, creates a problem at a distance, silent failure in the module? Obviously, a reliable writing module is right for you if you feed it garbage. But should / should .... it is up to the author of the module. As for you , you can raise something to the warning that might have been quiet before. Given that this is such an easy debugging step, it might be worth a try before going through the code with the debugger.

You have already found this, but for other perllexwarn readers the difference between -w, using warnings and $ ^ W. is discussed.

Answer 2

Quoth documentation :

ERRORS

The -w switch is optional.

Use -w . Any module that gives “odd warnings” when -w is turned on is poorly encoded and should probably be avoided, and old modules should be updated.

Answer 3

Enable warnings with either -w or explicit use warnings; until it causes a problem with another module. This is not that the guy is actively mistaken, as he is faced with unusual circumstances that most people do not encounter.

At the moment when the module gives warnings that you cannot fix, consider turning off the warnings selectively when loading this module, but consider whether there is a better alternative module without warnings. Over the past few years, I have not encountered problems with many modules; I have never had to use warnings selectively. And I have many modules (although I use them less than I probably should).

Answer 4

I am the one who initially made the comments he mentions, and I specifically thought about this class of modules:

• http://metacpan.org/author/MLEHMANN
• http://deps.cpantesters.org/depended-on-by.pl?dist=common-sense-3.4

Most of them are great tools that do weird things and have good reasons to avoid warnings. This is especially true for event loops in which performance is important.

Now, keep in mind, I said this on the starter mailing list. My advice was aimed at people who can barely debug their own code. Providing them with the possibility of warnings around the world, they do not write in the code, do not control and very often do not even understand, just ask about problems. Often they do not even understand (or do not remember) why they receive these warnings.

-w should be used only when you understand exactly what you are getting.