in reply to Re: My confession - I'm now strict-ing...
in thread My confession - I'm now strict-ing...

The latter only helps you to think more carefully when using package variables.

And thus makes your code better. use strict; doesn't improve the code, it forces (well, unless you really resist) YOU to improve your code.

It's like a warning sign. The piece of plastic or tin with some writing doesn't make the appliance safer in itself, it helps you think more carefully before doing something dangerous. And thus actually does make it safer.

Jenda
Enoch was right!
Enjoy the last years of Rome.

Replies are listed 'Best First'.
Re^3: My confession - I'm now strict-ing...
by JavaFan (Canon) on Jan 25, 2010 at 10:09 UTC
    And thus makes your code better. use strict; doesn't improve the code, it forces (well, unless you really resist) YOU to improve your code.
    Actually, it doesn't force you. When it comes the variables, the easy way out is just sticking 'our' in front of all the undeclared variables, or my()ing them on the top level. It does satisfy strict.

    I really hope people don't think that's an improvement of the quality of the code.

    Note, I'm not saying one shouldn't use strict. But strict isn't a silver bullet, and its presence on itself in code doesn't mean much.

      I would argue that, yes, that is an improvement in the quality of the code, in two respects:

      1) By forcing you to declare your variable names - even if only with our - it offers a good degree of protection against inadvertently creating new variables when you intend to reference existing ones, but misspell them.

      2) A my at the top-level scope of a module will keep that variable contained to the module, preventing weird inter-module dependencies such as those the OP encountered with his wanton use of do.

      But, yes, you are right in that just blindly sticking my/our in front of every variable that strict complains about won't get you the full benefit of strict. Like any tool, it works best when you think about how you're using it.

        A my at the top-level scope of a module will keep that variable contained to the module, preventing weird inter-module dependencies such as those the OP encountered with his wanton use of do.
        If you put a my there, yes. But not if you put an our there. And that's fine with strict. Or if you use $::var, no my or our needed, strict still happy.

        And in general, I rather see do not being used in favour of use/require and a separate namespace, than the code using do modified to satisfy strict.