Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid
 
PerlMonks  

Why use strict/warnings?

by Mr.T (Sexton)
on Aug 09, 2001 at 22:47 UTC ( #103559=perlquestion: print w/ replies, xml ) Need Help??
Mr.T has asked for the wisdom of the Perl Monks concerning the following question:

Hello Fellow Monks:

I am still new at Perl, and was noticing on many home nodes here, that most people agree that one should always use "strict" and "warnings".

My question is mainly, why should I use strict and warnings when I am writing programs in Perl?
  1. Does it really improve the script, or help it that much that I should always use them?
  2. Or is it just something to help catch errors when debugging, etc.


Thanks for any suggestions or help on this topic!

Mr.T
qw/"I pity da foo' who don't use Perl!"/;

Comment on Why use strict/warnings?
Re: Why use strict/warnings?
by suaveant (Parson) on Aug 09, 2001 at 22:57 UTC
    It helps improve you programming by catching spelling errors and little sloppy bits of code... there is no efficiency boost, and in fact, it's not a bad practice to comment out warnings and strict in production code. (at least that is my impression, tho I don't think it makes a huge efficiency boost)

    It is an excellent way to keep you from making some common mistakes, though... and that is worth a lot right there.

                    - Ant
                    - Some of my best work - Fish Dinner

Re: Why use strict/warnings?
by Agermain (Scribe) on Aug 09, 2001 at 22:57 UTC
    Why use strict?
    (warning: I might be dead wrong about this, but this is how I understand it) Assume you have a subroutine, and you set a variable called $mystuff. You also have a variable called $mystuff in your main program. use strict will keep you from running the program if you try to use $mystuff in your program without indicating which $mystuff you're talking about. This sounds harmless, but it's harder to figure out without using strict since you can't tell where your variable's getting screwed up - the subroutine or the main program. End result: Strict makes sure you keep your variables where they belong, rather than referring to some other structure (subroutine, module, etc.)'s variables.
    Why warnings?
    They help you figure stuff out. From experience, it's a lot easier to fix your program when you're writing it, than once it's already been installed and otherwise working!

    andre germain
    "Wherever you go, there you are."

Re: Why use strict/warnings?
by mischief (Hermit) on Aug 09, 2001 at 23:00 UTC

    Using strict or warnings doesn't actually improve your script on its own, but it does stop you repeatedly making the most common mistakes. strict forces you to be more, well, strict about your code. For example, you have to localise your variables using local or my before you can use them. This means that you know for sure that you're not overwriting some other important variable that will be used later on in your script, and you're not going to do something with a variable that you assume has no value, but is really 3.14259 and causes seemingly random errors to come up. warnings is a little different, because it doesn't force you to do anything, but it does warn you about stuff that is possibly or probably an error.

    Also, if you don't use warnings and strict, and you post something like "why is this failing?", when warnings or strict would have explained what's going on for you, you're probably not going to get much help. At least, you'll get told to use strict a lot. :-)

Re: Why use strict/warnings?
by runrig (Abbot) on Aug 09, 2001 at 23:08 UTC
    • strict can catch some really stupid errors (at compile time), like typos in your variable names. Or accidentally using symbolic references.
    • Warnings can catch things like variables that you forgot to initialize.
    • strict can keep you from doing some bad things, but doesn't prevent you from still writing bad code. It forces you to declare variables with, e.g. my or our or prefixing it with a package name. Variables are usually best declared in as narrow a scope as possible, so they're easy to keep track of, but prefixing a variable with a package name, e.g. main::myvariable, let's you go back down the dark path of having all globals and creating them off in hard to find included (require, do) files and modules, or declaring all of your variables with my at the top of your script.
    • Small scripts (ten lines? one page or less? one-liners? it's up to you) don't really need strict or warnings, but if something goes wrong that you can't figure out, it might be a good idea to turn them on as a first step.
    • If you submit chunks of code for our review here asking for help, and you obviously haven't used strict or warnings, it can be harder to guess at what the problem is.
(jeffa) Re: Why use strict/warnings?
by jeffa (Chancellor) on Aug 09, 2001 at 23:08 UTC
    Take a look at this. See those guys? If you don't use strict (they are lax on warnings), they will hunt you down and say mean things to you.

    Seriously, the _best_ reason i can think of is 'it will save you time and keep you from stressing out'.

    I had recently found myself getting very lax at using strict and warnings, and it was showing! The average programmer makes typos, lots of them. Strict and warnings will help you catch those typos, don't use them and you will waste your time trying to understand why your program is not working correctly, even though it compiles.

    So, if you are really good at 'guessing' why your program is broken, then don't bother with strict and warnings, but if you cherish the hairs on your head and a calm stomach, please use them. :)

    perl -le '$x="jeff";$x++ for(0..4482550);print $x'

Re: Why use strict/warnings?
by dga (Hermit) on Aug 09, 2001 at 23:14 UTC

    My observations on why and why not to use some pragmas

    #!/usr/bin/perl -T use strict; use warnings;

    strict also does some runtime checking of your code and as such probably should be left in for production.

    use diagnostics loads up a big overhead on startup and probably should only be for debugging due to the performance hit.

    Also one should put -T on the #! line of any program which takes user input to detect a host of other insecure coding practices.

    warnings dont seem to pose any noticeable delay and if your code emits no warnings then its probably easier to maintain that code that dumps a bunch of them.

    Finally, strict and warnings on and silent will earn you points with the person who inherits the code base from you to maintain.

Re: Why use strict/warnings?
by FoxtrotUniform (Prior) on Aug 09, 2001 at 23:59 UTC

    Just thought I'd throw in something else that I haven't seen posted yet: saying

    use strict;

    lets anyone else who reads your code know that you know what you're doing, which makes a difference when they read it. (They can, for instance, assume that if they see an unqualified variable in a subroutine, it's local to that sub, and not some sort of magic state that affects other parts of the code.) This makes your code easier to read, which makes everyone happier.

      That's all well and good, until you see the next line:

      use vars qw($CONFIG $my_loop_var $fileno $window_size ....)

      Perhaps we need a new pragma:

      use Schwern;   # Schwern is my bitch.

      I'm sure the people reading the code would get the gist then.

Re: Why use strict/warnings?
by RayRay459 (Pilgrim) on Aug 10, 2001 at 00:53 UTC
    i am new to perl, and i have started using these with all of my scripts. There is no "boost", but if something is wrong in your script, it will give a little more info. That can mean the difference in spending an hour to fix a script or 5 mins. : ) Ray

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://103559]
Approved by root
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chanting in the Monastery: (11)
As of 2014-09-22 08:57 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (185 votes), past polls