Документация
HTML CSS PHP PERL другое

1.6 Strictness

 
Previous Table of Contents Next

1.6 Strictness

The most common cause for grief in inheriting a Perl program is the absence of these two magic lines from the beginning of every file:


use warnings;

use strict;

If the program contains a -w on the #! line, that counts the same as a use warnings in the main program and every module that it uses. Because the use warnings pragma is a relatively recent addition to Perl (version 5.6.0 or later) you're more likely to find the -w flag in inherited programs.

Why these lines are not the default for Perl programs has been the source of much contention between certain people in the Perl community, including me. But they aren't the default, so we're stuck with the situation. Omitting these lines from a Perl program is as close to professional suicide as you can get this side of putting a whoopie cushion on the CEO's boardroom chair. In case you're not aware of how important these lines are, I'll go into more details on their effects in Chapter 5. First let's deal with what you should do if you are handed code that lacks them.

If you have the opportunity and the chutzpah, hand the program back to the developer who wrote it, and as politely as you can, ask them to add use strict and use warnings (or -w) to the code, and let you have it back after they have fixed the code so that it runs without errors or warnings. (If the code includes modules written by the developer, each one of them should include a use strict at the top, and a use warnings if the main program isn't using the -w flag.)

This is not the time to tell them that doing this will almost certainly result in dozens of fatal errors, hundreds of warnings, and numerous changes required of the code in order to make it compliant with these new directives.

They will think that your request is a trivial addition. Let them. The changes they make to enforce compliance will make your job immeasurably easier, because the way they choose to resolve each error or warning will be based on understanding of the code that they have and you do not.

If you think this tactic is underhanded, you haven't yet tried to maintain a significant body of code that was developed without use strict and use warnings. After doing that, you'll be inclined to approve far more stringent forms of punishment for a developer who omits them. The rack, for instance.

    Previous Table of Contents Next
    © 2000- NIV