Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight

to strict or not to strict

by castaway (Parson)
on Oct 16, 2003 at 20:49 UTC ( #299878=perlmeditation: print w/replies, xml ) Need Help??

YASD (Yet Another Strict Discussion)

... But this one has already been had, I thought I'd share it with the rest of you.. Enjoy (or not :)

2003-10-16 09:58:26 <castaway> demerphq, thats all your fault.. now theres a 'use strict' in the patch..
2003-10-16 10:01:21 <demerphq> Heh. Thatll learn ya!
2003-10-16 10:01:24 <broquaint> castaway: the 'use strict' shouldn't affect your code though, (lexically scoped pragmas)++ # no need for shotguns
2003-10-16 10:01:43 demerphq high-fives theorbtwo
2003-10-16 10:02:33 <castaway> what'd he do?
2003-10-16 10:03:29 bart thinks basically that theorbtwo is a strict fan
2003-10-16 10:03:34 <demerphq> I was kidding...
2003-10-16 10:05:04 <demerphq> I have to say that I find it marginally shocking that a woman of your intellignece doesnt use strictures castaway. You should post a meditiation on it. :-)
2003-10-16 10:06:29 <castaway> Im pretty sure I have at least one script/module with it in (more or less by accident) - I just find it more annoying than helpful.. *shrug* (and there are already some 'dont use strict' nodes :)
2003-10-16 10:07:05 castaway does a grep -r strict * ..
2003-10-16 10:07:12 <bart> I've not been using strict myself for years. Occasionally I stll do. "use strict 'refs';" was the first thing I did with it.
2003-10-16 10:07:54 <demerphq> feel free to point me at one of them.
2003-10-16 10:08:07 <demerphq> not using strict is IMO insane. Sorry. :-)
2003-10-16 10:08:24 <castaway> hmm, 1 by me, several that other people seem to have sneaked in..
2003-10-16 10:09:02 <bart> The latter is useful, castaway. It prevent symbolic references and things like $foo{bar} = 'baz'; $foo{bar}{bleep}++;
2003-10-16 10:09:45 <liz> demerphq: I agree, not using strict is not very wise..
2003-10-16 10:10:09 <demerphq> the amount of time that they save you in debugging far outweighs the time it takes to type it in.
2003-10-16 10:10:09 castaway religously used {'text'} and not {text} in hashes, and never uses symbolic thingummys anyways.. *shrug*
2003-10-16 10:10:37 castaway thought Ovid wrote one, trying to find it..
2003-10-16 10:10:42 <castaway> wanna bet? :)
2003-10-16 10:10:51 <bart> castaway you seem to have overlooked the culprit. :].
2003-10-16 10:11:14 <bart> $foo{'bar'} = 'baz'; $foo{'bar'}{'bleep'}++; still has it.
2003-10-16 10:11:24 virtualsue routinely uses strict for scripts longer than a few lines, but doesn't worry much about it
2003-10-16 10:11:50 <castaway> you're changing a scalar hash val to a hashref.. and?
2003-10-16 10:12:20 <bart> It's using "baz" as a symbolic reference.
2003-10-16 10:12:52 <demerphq> yeah, where he talks about TheDamian and whatshisface that wrote CGI. Have you looked at the code in CGI? Its not one to set any metrics. And thedamian is, well thedamian :-)
2003-10-16 10:13:01 ybiC wonders if the Webmistress who doesn't hesistate to use strict; will weigh in on this discussion.
2003-10-16 10:13:57 <bart> It sets %baz to ( 'bleep' => 1 )
2003-10-16 10:14:16 castaway peers at bart
2003-10-16 10:14:18 castaway does a test..
2003-10-16 10:15:59 <bart> Adding use strict 'refs' gives a runtime complaint: "Can't use string ("baz") as a HASH ref while "strict refs" in use at ..."
2003-10-16 10:16:24 <castaway> setting use strict in my code appears to just get me a heap of 'Global symbol needs explicit package name' .. nothin else
2003-10-16 10:17:05 <bart> Well... yes... but that's just use strict 'vars';
2003-10-16 10:17:45 <demerphq> And thats a good thing castaway it catches typos and forces you to _think_ about the globals you are using.
2003-10-16 10:17:56 <bart> If you work with complex, variable depth data structures, like my example, stict 'refs' is extremeley useful.
2003-10-16 10:18:07 <castaway> yeah, but my code complies else, so why use it? :)
2003-10-16 10:18:40 castaway does think, doesnt need some pragma to do that for her ,)
2003-10-16 10:18:59 <bart> So my example wasn't convincing enough? Even though Perl found more errors than you did?
2003-10-16 10:19:36 <castaway> nope
2003-10-16 10:19:44 <demerphq> castaway I just said to broquaint elsewhere: "Im Lazy. I prefer the compiler to find my stupid errors for me. Ive got enough on my hands dealing with the _difficult_ errors. :-)"
2003-10-16 10:20:16 demerphq wonders when a competent perl programmer doesnt work with complex data structures.
2003-10-16 10:20:53 <liz> castaway: I find that by using strict, I don't have to think about misspelt variable names anymore, freeing my mind for other, more fun stuff
2003-10-16 10:21:13 <demerphq> liz++
2003-10-16 10:21:14 <castaway> lazy programmers, the lot of ya ,)
2003-10-16 10:21:28 <castaway> liz thats to me a good reason *not* to use it
2003-10-16 10:21:57 <Yendor> Lazy programmers are the best kind.
2003-10-16 10:21:58 <demerphq> castaway that comment makes no sense.
2003-10-16 10:22:19 <tilly> castaway: I didn't think that I needed for many years as well. It annoyed me more than it helped. 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.
2003-10-16 10:22:30 <castaway> in fact Im getting convinced that not using it forces me to code+debug better..
2003-10-16 10:22:30 <bart> castaway If I hadn't said what my code snippet did, how long would it have taken you to figure it out by yourself?
2003-10-16 10:22:53 hardburn finds careful use of no strict 'refs' to be very useful
2003-10-16 10:23:02 <virtualsue> you can drive better when you drink, too, because you need to be more careful ;)
2003-10-16 10:23:17 <castaway> bart I dunno, gimme a code piece that misuses it, and I'll tell you..
2003-10-16 10:23:47 tilly recognizes castaway making the same arguments that he used to...
2003-10-16 10:24:16 <demerphq> certainly hardburn I do the same. but turning it off for carefully considered localized blocks is entirely different than no using strict at all.
2003-10-16 10:24:39 <castaway> they're arguing.. *shrug* ,9
2003-10-16 10:24:48 liz agrees with hardburn as it puts a marker as to where strange things might happen
2003-10-16 10:25:44 liz also thinks you can bring a horse to a drinking pool, but you can't force it to drink...
2003-10-16 10:26:21 <liz> or should that have been "camel" instead of "horse" ;-)
2003-10-16 10:26:49 bart points castaway to the source of Exporter
2003-10-16 10:26:53 <castaway> Camels are even more obstinate :)
2003-10-16 10:27:24 <demerphq> tilly: the use of past tense suggests you have changed your position on the subject?
2003-10-16 10:27:44 <castaway> anyfish, I seem to program to strict without actually using it.. think whatever you like about that..
2003-10-16 10:27:56 castaway hands demerphq a cbhistory
2003-10-16 10:28:34 bart points demerphq to cbhistory, while he's at it.
2003-10-16 10:29:13 <bart> castaway if that were true, you wouldn't object to it so much.
2003-10-16 10:30:07 <bart> If there's anything I hate about it, it is how syntax errors, like mismatched braces, produce a lot of complaints from strict.
2003-10-16 10:30:08 <demerphq> oh indeed. I did overlook that.
2003-10-16 10:30:34 <castaway> bart thats your opinion
2003-10-16 10:30:54 <castaway> 'more or less' to, then..
2003-10-16 10:31:39 <virtualsue> !
2003-10-16 10:31:50 <castaway> yummy, 3 pages of 'Global XYZ' in cbgateway, nothing else
2003-10-16 10:32:58 <demerphq> All i know is every time ive turned strict on in my code when ive allowed a one liner without it to grow without adding it, ive found errors. and same for other peoples code without it.
2003-10-16 10:33:10 <bart> IMO strict shoudl hold its complaints until a script compiles properly otherwise.
2003-10-16 10:33:22 <castaway> (and who said I objected, I just dont use it ,)
2003-10-16 10:33:33 <demerphq> If you look at strict as a sort of moral discouragement of globals its worthy on that level alone.
2003-10-16 10:34:03 <castaway> I like globals, they have their uses
2003-10-16 10:34:27 <liz> not to mention all of the errors found by Test::Harness forcing warnings on test-suites... ;-)
2003-10-16 10:34:43 <bart> That I disagree on. Globals are not bad. Especially not in modules, where you want to allow people to access it from their scripts.
2003-10-16 10:36:17 <castaway> depends on your definition of errors, demerphq .. :)
2003-10-16 10:36:30 <castaway> I wouldnt say strict just catches errors..
2003-10-16 10:36:36 <demerphq> Globals are evil except when you can explain why they arent. Requireing them to be declared is like a little mental reminder:"do I really need a global for this?"
2003-10-16 10:36:36 <liz> bart: I disagree with that: globals need to be accessed with class methods in my book...
2003-10-16 10:37:37 <demerphq> liz class method interfaces dont allow localization easily.
2003-10-16 10:37:38 <bart> For example, those conversion hashes in HTML::Entities. Even though most code doesn't use it, you don't want to force people to rewrite the same code if they ever need direct access to them.
2003-10-16 10:37:41 <liz> so that you have the option of changing the underlying interface in the future
2003-10-16 10:38:25 <bart> liz that's OO only. procedural programming doesn't work that way.
2003-10-16 10:38:51 castaway thinks she'll filter this lot outta the log and post it as a node ,) (unless anyone objects..)
2003-10-16 10:39:16 <liz> demerphq: I assume you mean {local $Other::Module;:var; } automatically restoring?
2003-10-16 10:39:27 <demerphq> there is a time and a place for globals and dynamics. but if your design and code is clean they shouldnt come up often.
2003-10-16 10:39:32 broquaint expects royalties
2003-10-16 10:40:20 <bart> A module shouldn't expect to do everything for everybody. Sometimes its own building blocks are useful for other stuff as well.
2003-10-16 10:40:26 <tilly> demerphq: In many cases you can roll localization of anything with ReleaseAction. :-P
2003-10-16 10:41:05 <liz> bart: I guess I only do OO with modules then... that's true...
2003-10-16 10:41:08 <bart> Otherwise, you'd just be adding bloat for the common cases.
2003-10-16 10:41:27 <diotalevi> I'll echo bart. I wrote Stealing lexicals - best practice suggestions just because the module tried to keep something private it shouldn't have. I dunno - module's data might be always better off being global unless it can be explained why it should be private.
2003-10-16 10:41:31 <bart> (code bloat)--
2003-10-16 10:42:07 tilly wonders if bart is familiar with the concept of "loose coupling"...
2003-10-16 10:44:30 <bart> "loose coupling"? In software? Eh.. no... I don't think so.
2003-10-16 10:46:49 <tilly> Loose coupling is the idea that different sections of code should not have too strong a web of interdependencies because those dependencies is what breaks.
2003-10-16 10:47:17 <castaway> there, now we're running strict (+ no 'vars') - happier? ,)
2003-10-16 10:48:11 <tilly> Going after someone else's global is an easy way to solve your immediate problem. But it erodes the overall maintainability of your code because you now have a hidden dependency. Over time that turns you into fragile spaghetti.
2003-10-16 10:48:12 <bart> I thought that was what you're referring to, tilly. However, some data structures should be considered so basic that you never evr need to change their basic structure. The hashes in HTML::Entites is a good example.
2003-10-16 10:48:28 <castaway> 'defined interfaces', tilly (between subs as well as modules..)'
2003-10-16 10:48:32 <demerphq> tilly that looks pretty cool. ill have to keep it mind next time I need something like that. I like it. imagine its use in a 3arg for loop. :-)
2003-10-16 10:49:35 <tilly> Let me read the source to HTML::Entities...
2003-10-16 10:50:32 <bart> That module optionally exports those hashes. So that goes even one step further.
2003-10-16 10:51:17 <tilly> That one is a pretty good example. But only because it is a published RFC, implemented in many different browsers as well as in HTML::Entities.
2003-10-16 10:52:08 <tilly> But examples which are that clear-cut are darned rare.
2003-10-16 10:52:20 <bart> Exactly. That's why I still prefer to use %HTML::Entities::char2entity
2003-10-16 10:53:06 <demerphq> tilly I borrow Data::Dumper quote() quite often. :-)
2003-10-16 10:54:07 <castaway> (hmm, no-one happier? shall I take 'em back out? :)

..... Make of it what you will :) - I'm still not convinced, anyone else?


Replies are listed 'Best First'.
Re: to strict or not to strict
by BrowserUk (Patriarch) on Oct 16, 2003 at 22:20 UTC

    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'; .... };

    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.

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

      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..


      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

        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 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,

        '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.
Re: to strict or not to strict
by perrin (Chancellor) on Oct 16, 2003 at 21:47 UTC
    I just don't have the patience to find all the things that strict (and warnings) finds for me by hand. It slows me down too much if I don't use it.
Re: to strict or not to strict
by runrig (Abbot) on Oct 16, 2003 at 22:02 UTC
    strict catches my tyops before the program even starts running (in a manner of speaking). So anything over 5 or 10 lines gets strict. Unless I really need symbolic references, that is. But then, my name's not Damian, so I don't need them very often :-)

    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

      -- Mike

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

Re: to strict or not to strict
by revdiablo (Prior) on Oct 16, 2003 at 22:59 UTC

    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.

Re: to strict or not to strict
by rob_au (Abbot) on Oct 16, 2003 at 22:55 UTC
    <monty-pythonesque>Beware castaway - Nobody ever expects ... the Code::Police!</monty-pythonesque>



    perl -le "print+unpack'N',pack'B32','00000000000000000000001010001010'"

Re: to strict or not to strict
by Anonymous Monk on Oct 16, 2003 at 22:57 UTC

    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.

Re: to strict or not to strict
by Nkuvu (Priest) on Oct 16, 2003 at 21:28 UTC

    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.

      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.
Re: to strict or not to strict
by antirice (Priest) on Oct 17, 2003 at 02:38 UTC

    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. 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.

    The first rule of Perl club is - use Perl
    ith rule of Perl club is - follow rule i - 1 for i > 1

      ...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; }

      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% --

      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.


        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{}; 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% --

        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.




Re: to strict or not to strict
by nimdokk (Vicar) on Oct 17, 2003 at 12:51 UTC
    One reason I always turn strictness on in scripts (apart from a quick test of a tiny bit of code) is to help keep me from doing things that I probably shouldn't. I encountered a problem once that setting no strict 'refs'; would have fixed but after discussing the issue here, I came up with a better way to do it. I was concerned that by doing what I was, I might cause problems elsewhere in the script. Another reason I leave strictness on by default in our production scripts is because the people I work with are not as familiar with Perl as I am (of course that's not saying much :) and with strictness on, it helps to prevent typos or setting variables that should not be set. Most of the code is essentially plug-n-play (fill in the values for the variables you need and only use the relevant pre-written code blocks), but when something needs to be added, it helps keep us honest about what we are doing.

    "Ex libris un peut de tout"
Re: to strict or not to strict
by tilly (Archbishop) on Oct 20, 2003 at 15:05 UTC
    Reading this thread is interesting, because I can see myself not too many years ago in castaway's position.

    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 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 is also true. Of course it didn't convince you. But I can understand that. You see, I resisted using 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, 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 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, 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, 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.

Re: to strict or not to strict
by Anonymous Monk on Oct 17, 2003 at 00:29 UTC
    A good reason to "use strict" is so you're not told to "use strict" when you come around here with a problem.

      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.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://299878]
Approved by broquaint
Front-paged by broquaint
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others imbibing at the Monastery: (7)
As of 2023-12-05 09:22 GMT
Find Nodes?
    Voting Booth?
    What's your preferred 'use VERSION' for new CPAN modules in 2023?

    Results (26 votes). Check out past polls.