Tags:
create new tag
, view all tags

The importance of using the use strict; pragma

For normal mortals

All modules, including extension modules, should have use strict; in them.

So, if you encounter any code without use strict; in it, treat it with the utmost suspicion. If it's plugin, you can give it a low mark in the "Implementation Quality" section of the appraisal.

For programmers

Fom the excellent materials at http://www.perltraining.com.au, dug up by MartinCleaver

If you’re writing code that’s anything longer than a few lines, then it’s strongly recommended that you make use of Perl’s use strict pragma, and the use warnings pragma or -w switch.

The benefits of using strict and warnings are simple and straightforward. These pragmas ensure that the vast majority of common programming mistakes that can be automatically detected are detected.

The use strict pragma defends primarily against typographical errors, such as typing $freind where one meant $friend. The use warnings pragma defends primarily against logic and programming errors, such as using an undefined value as if it were defined, printing to a closed filehandle, or treating a string as if it were a number. Using strict also naturally encourages a higher level of encapsulation and better design. Once your code works cleanly with strict and warnings, only more difficult and time-worthy bugs will remain. There is simply no reason for programmers to waste valuable time debugging a problem caused by a spelling error when modern programming languages are capable of doing this for them. It is acceptable to turn off strict and/or warnings for some sections of code, but only when the programmer knows exactly why they are doing so. An excellent example would be using no strict ’refs’ in an AUTOLOAD to call subroutines from their names contained in scalar variables. "

Examples

You can have some geeky fun pretending to be use strict and finding the errors yourself:

my $BEAST = 666;
# Loop over each number of the beast and announce its demise
while ($BEAST) {
    print "Hallelulah! Beast #".($BEA5T--)." has been slain!\n";
}
print "The beasts are all dead!\n";
On casual inspection, there's nothing wrong with that (well, if you stare at it with your eyes half closed anyway). use strict would have nailed the error instantly.

my $BEA5T = 0;
# Loop over each number of the beast and announce its demise
while ($BEAST < 666) {
    print "Hallelulah! Beast #".($BEAST++)." has been slain!\n";
}
print "The beasts are all dead!\n";
This code sort of works with mod_cgi. With mod_perl, there's a subtle difference: It works, when you test it. It works for the colleague who tests it. But it fails for others. That is because it works exactly once for each process after server startup. Here's why: Due to the typo, $BEAST is never initialized, so without use strict; it is automatically initialized as 0. The loop works from 0 to 665. However, due to the same typo, with mod_perl, the next time the code is run in the same process $BEAST starts with a value of 666, retained from the previous invocation. No more beasts are slain, and the programmer is cast into limbo for eternity.

Note that the value of use strict; has diminished with newer releases of Perl which allows constructs where it fails:

  1. It catches undefined scalars like $BEA5T - but it fails to catch $hash{BEA5T} if %hash is defined. All of TWiki's objects are hashes.
  2. It can not catch undefined method calls like $twiki->writeCompleteNonsense because, thanks to autoloading, "missing" routines can pop up during runtime.

-- Contributors: MeredithLesly, SteffenPoulsen, CrawfordCurrie, HaraldJoerg

Edit | Attach | Watch | Print version | History: r35 < r34 < r33 < r32 < r31 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r35 - 2006-07-17 - CrawfordCurrie
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.