I started useing strict in my 3rd ever attempt at a perl script, and I've never seen a reason not to use it. I'm far from susceptible to peer pressure, nor a natural follower of "rules", but with the exception of an occasional no strict refs'; in import() routines, usually done as

my $something = do{ no strict 'refs'; .... };
[download]

I honestly can't remember ever having had a 'problem' with it. It's put at the top of every script automatically when I create a new .pl file in my editor, and it's just there. If and when it emits an error, I just correct the error. Some warnings I could willingly do without, but strict never seems to interfere in what I want to do.

Could you (or anyone) explain why they don't use strict, in terms of how it interferes with your code? A few examples of the ways in which you "find it more annoying than helpful" would be interesting, and would add to my education.

Please believe me, that isn't sarcasm or irony, I tried 3 different times to word it in a way that was less misinterpretable. I would genuinely like to understand why obviously competent people choose not to use it, and what techniques I am excluding myself from by doing so.

I tried, but I think I failed.. I guess its more indifference. Possibly I just dont like a compiler telling me how to code. i.e. if I want to use globals, or symrefs, thats my problem. It allows them quite specifically, so why can't we use them? That's not to say that I do liberally (most of my globals are probably unintentional..). So rather than turn the thing (which, as we all know, is optional, else it'd be built-in :)on, and turn it off for bits of code where I need it, I leave it off.

It's pretty amazing that this is such a discussion point in this TMTOWTDI language (sorry broquaint, paraphrased your words there).. It's like some sort of religion, in fact in my case more so.. Some say 'you must' some 'you musn\'t', and me, I don't really give a *wotsit*. (In both cases ,)

Did that explain any better? Probably not.. So I'll stick with my 'I\'d rather debug myself and be better at coding for it, than let some pragma do it for me.' reason.. Pick one..

C.

The general consensus seems to be that without 'strict', you code badly. I don't agree. (And several people that have seen my code don't seem to either..)

Possibly I just dont like a compiler telling me how to code

The compiler does that whether you use strict, though! That's why this is not a valid Perl program:

Prin "hellol;

I'd rather debug myself and be better at coding for it

I think that's a rather shortsighted view and a rather lame excuse.

I expect good programmers not to waste their time wanking over manual tasks that the computer is much better at doing reliably. Do you refuse to write automated test suites because you want to demonstrate your mad debugging skills?

Maybe you never make any typos. Maybe you've never spent an hour searching for a problem that doesn't make any sense and finally realized that you wrote $customr when you meant $customer. Since you say, though:

most of my globals are probably unintentional..

I wonder why you wouldn't want something to catch your unintentional errors immediately.

I find it hard to believe that anyone who's written anything longer than Hello, world hasn't been bitten by those errors, and that's why I suggest that refusing to let the computer catch common mistakes is a waste of your time.

Well, I will certainly never be the one to suggest that you should use it. I was more interested if there was a technical, as opposed to personal/ideological reason why you chose not to. If your happy, or just happier, without, then that's both your prerogative and good enough for me. My own use of strict is religious, but definitely not Religious. And even if it were the latter, I would never try to 'convert' anyone to it -- there's nothing more annoying in my book:)

From my own perspective, I'm more than happy to allow the computer to take care of as many of the mundane tasks that are involved in programming (and the rest of life) as I can pursuade it to do. That's the essence of programming and computers for me, getting this extremely fast, always willing, supremely dilligent and never forgetful, but essentially dumb assistant to do the stuff that I get bored with. In fact, given the choice there are a whole heap of things that I think that my editor/perl/OS could do for me that they don't (yet).

---

Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
Hooray!

So I'll stick with my 'I\'d rather debug myself and be better at coding for it, than let some pragma do it for me.' reason.

Sorry but that doesn't really make much sense to me. Why wouldn't you want the compiler to help you out? You can still learn from it. Personally I'd rather do a perl -c myprog.pl and have the compiler complain instead of assuming everything is ok and finding a subtle bug later on.

-- vek --

I'm still a noob Perl guy, however warnings and strict seems to have improved my understanding of perl by swatting me on the hand with 'so called bad habits.' I have a couple questions for you and am interested on your points a view concerning beginning programmers...

Do you reccommend new perl programmers to use or not use strict and/or warnings? Why?

If you were in an interview for a job you really wanted and the interviewer asked if you use strict in your code what would you say?

Looking for enlightenment,
Belmonts

'I\'d rather debug myself and be better at coding for it, than let some pragma do it for me'

You remembered to backslash the single quote! You must be a master of minor details and you probably never make any typos or bugs. I wish all my coworkers were just like you!

Okay, but I have to do things in the real world. Have pity on me. :-)

"Then I had one too many programs crash from a typo in a variable in an if branch I hadn't tested, and saw the light." -- tilly

"All i know is every time ive turned strict on in my code . . ., ive found errors. and same for other peoples code . . ." -- demerphq

Trust me on this one. You only need to do two things to see the "light." Take a Perl program of more than a few hundred lines, maybe something that you have not touched for a year, and do this:

1. Add "use strict;"
2. Add "my" or "our" to the first time each variable is used. This will shut off most of those warnings that you are getting.

Did you try it? Did you find a couple of misspelled variable names? Are you suprised that you found any? If you didn't find any, now you are sure that the code is perfect.

The general consensus seems to be that without 'strict', you code badly. I don't agree.

Have you ever made a typo in your code? How can you be sure there are none?

most of my globals are probably unintentional

<rant>You'd feel more strongly about this after being forced to work on code that has only global variables, many of which are one letter long. And the code is broken into multiple files. Which all use package main. Thankfully Perl gives you a way to work around this with "my" and/or "local." But it's still bloody sick. Maybe you (not YOU, but the person who did it) know that $j is the filename for the currently selected input file, but nobody else knows that. . .</rant>

The general consensus seems to be that without 'strict', you code badly. I don't agree.

No, I do not think it is the general consensus that with strict one codes badly. I think the general consensus is that with strict one can be sure that a certain class of errors is avoided. strict is the difference between careless and careful programming, not between bad and good code.

Update: I only remember using symrefs once.

And of course, if you really did need symbolic refs, one of the great things about strict (and warnings too) is that you can disable it locally:

use strict;
# symbolic refs are disallowed here
{
    no strict 'refs';
    # use symbolic refs as much as you like here
}
# symbolic refs are disallowed here too
[download]

-- Mike

--
XML::Simpler does not require XML::Parser or a SAX parser. It does require File::Slurp.
-- grantm, perldoc XML::Simpler

Perhaps some pointed analogies would help explain the reason I (and I assume most everybody else) like to code with strictures on as much as possible:

• "I don't wear my seat belt because I drive really really carefully, and think about what I'm doing, so I don't need it."
• "As long as I am very careful, I can easily change out an electrical switch without first shutting off the power."
• "I always open boxes by cutting towards myself. Turning the box around is very annoying, and much more awkward. As long as I cut carefully, I will be fine."

While all these things may or may not necessarily make sense, and might seem rather extreme compared to a silly mistyped variable name, I think they illustrate the point. Using strict is not about what happens when everything goes right, but about what happens when something goes wrong. It's not an admission of incompetence or laziness, but a safety net.

Mistakes happen. To say otherwise is simply delusional. The strict pragma helps catch a large amount of common mistakes that might otherwise go unnoticed, or perhaps less noticed, without it. Do not let me try to change your habits for how you write your own code for your own use, but if I ever took over a project without appropriate application of strictures, I would certainly have many choice words for the previous author.

:-)

The programmer who always chooses not to use strict and warnings because of the emmision of annoying warnings or compile errors is a careless programmer (or a trivial programmer). strict makes non-trivial programming easier, not harder. Careful programmers may choose to disable one or more strictures for the duration of sections of code that require facilities that are disallowed by strict. There is little to debate, either you are careless, trivial, or strict.

I use strict; all the time. But I started programming in C/C++, so not declaring variables at the beginning of my code is just weird to me. ;)

Declaring variables at the beginning of your code is only very slightly better than not declaring them at all.

You should declare them just before you need them and only for the smallest possible block. IMHO of course.

Jenda
Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
   -- Rick Osborne

Edit by castaway: Closed small tag in signature

I do declare variables in the smallest scope possible -- but I do also put them at the beginning of the block. I find it's easier to organize, and I tend to think about my code more before I write it.

I only use strict and warnings in my code during development. (Academic note: Believe it or not, using strict creates overhead although it's not an optimization to write home about). I'm far from perfect. I know I can make spelling erors (<--see), not keep proper case, or just accidentally append a random string to the end of variable names due to my bashing my head against the keyboard. I may sometimes accidentally put $$array[0] instead of ${$array[0]}. Strict catches that (unless there's a $array, but I tend not to overlap variable names between list types and scalars). I consider not using strict during development to be synonymous with nailing two pieces of wood together in the dark. Sure, you can do it but the results may not be quite as pretty or as painless as they would be if you did it in a well-lit room.

...at least that's my opinion.

Updated: The reason I don't use strict in my production scripts is actually because I use a series of dev modules that set up my programming environment. These specify such nifty things as how die and warn should react as well as possibly setting up STDIN and %ENV for testing that particular script. I mentioned the overhead involved with using strict mostly as an academic interest. Why not list specifically use strict;use warnings; in my script? Because that is done from my dev module's import. I don't need the "optimization". I didn't mean to imply that I use it as an optimization. I don't comment out use strict;. use strict; is meant to help me program. So what difference does it make if it isn't present in production? When the scripts go into production, a blank dev module with only a version and a __DATA__ section with development notes is provided to give any future developers some hints as to how I created the software as well as development tests, the output, and any notes to go along with them. Sorry for the long update. I realized by the --'s on this post that I wasn't clear on what I originally meant to say.

...using strict creates overhead although it's not an optimization to write home about.

I assume you're referring to the runtime check for symbolic references, as that is the only run-time component for stricture?

$ perl -MO=Deparse -e '{use strict; my $a = 1}'
{
    use strict 'refs';
    my $a = 1;
}
[download]

Well, I've taken the liberty of benchmarking the use of strict refs, and I must say it's a meager optimization indeed. I ran this code on a (new) completely unloaded machine: it would seem to me that the difference is noticable, but seems to be drowned out by noise almost completely.

use Benchmark qw(:all);
cmpthese( 10000000, {
   with => sub {use strict 'refs'; my $a = 1; my $b = 2},
   without => sub {my $a = 1; my $b = 2},
} );
__END__
             Rate    with without
with    3378378/s      --     -7%
without 3623188/s      7%      --

             Rate without    with
without 3802281/s      --     -3%
with    3937008/s      4%      --

             Rate    with without
with    3412969/s      --    -15%
without 4032258/s     18%      --

             Rate    with without
with    4048583/s      --     -3%
without 4166667/s      3%      --

             Rate    with without
with    3460208/s      --     -9%
without 3787879/s      9%      --
[download]

It would seem to me that if you need this type of optimization, you'd better start coding parts of your program in C ;-). So I wouldn't remove "use strict" from a production script for this reason: the likelyhood of a "quick hack" in the future on that production script messing up things without warning, would be just too great for me, from a sysadmin point of view.

Liz

You benchmark only ever loads strict once making it marginally valid. If you start to factor in load times.....

use Benchmark 'cmpthese';
my %hash;
cmpthese( 10000000, {
   with => sub {delete $INC{strict.pm}; use strict 'refs'; my $a = 1; 
+my $b = 2},
   without => sub {delete $hash{key}; my $a = 1; my $b = 2},
} );

__DATA__
Benchmark: timing 10000000 iterations of with, without...
      with:  8 wallclock secs ( 9.10 usr +  0.00 sys =  9.10 CPU) @ 10
+98538.94/s (n=10000000)
   without:  3 wallclock secs ( 4.04 usr +  0.00 sys =  4.04 CPU) @ 24
+78314.75/s (n=10000000)
             Rate    with without
with    1098539/s      --    -56%
without 2478315/s    126%      --
[download]

You need to delete an imaginary hash key in the without to be fair. This a more realistic benchmark outside of persistent processes. Nonetheless the contribution of strict to the total overheads is trivial and I always use it.

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

castaway: What that you say is true. Automatic elimination of a couple of clsses of bugs will tend to encourage relative carelessness, just as the backspace key encourages poor typing. The benefits of strict.pm partly show up in reduced errors, and partly show up in needing to spend reduced effort to accomplish the same task. In my experience, both are worthwhile. And with experience, it isn't too hard to switch modes between relaxed and careful when you switch languages. (The first few times though...)

Of course what other people say about strict.pm is also true. Of course it didn't convince you. But I can understand that. You see, I resisted using strict.pm for a long time. Sure, I knew that lots of people used it. Sure, I knew all of the arguments for why it was supposed to be a good thing. But, like most people, I had some arrogance, I thought that I worked better than most, I was careful, I didn't need that crutch.

And exactly because this was a point of pride for me, it was hard for me to realize that I was making excuses for myself. After once too often crashing a production process because I wasn't using strict.pm, I got unhappy when a co-worker chided me because Perl's compiler was so loose that it made things like that hard to catch. Because I knew darned well that Perl did offer a solution, but I didn't want to admit that I just hadn't wanted to use it.

So I turned on strict.pm and caught another bug or two. Not long afterwards, I found that the best way to start fixing bugs in some of the other poorly-designed Perl that I had (my pride makes me point out that most of that was written by other people) was to start by turning on strict.pm, catching some bugs (possibly the one I had to fix) and at the least allowing me to proceed with confidence that a particularly annoying kind of bug to debug was now gone. Eventually, strict.pm became a habit. When I switch to languages with no equivalent, I curse a bit and then adapt back. But when I go back to having it, I relax a little, go faster, and enjoy myself more.

YMMV. But that is my experience.

You didn't type your text in all bold italics. You also should have used single quotes instead of doubles and ended the sentence with two periods. I suggest you do so from now on so that you're not told otherwise.

See my point? Didn't think so, I'll move along now.