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

The writing of the modules had to have strict in them. Why ? Because the folks that would be using the modules would be stricting, hence I couldn't have a module that would break other applications.
Huh? Strictness is lexically scoped - any module that uses strict can use a module that doesn't use strict. It won't break. In particular, any code that runs fine with strict, will continue to run fine, and in exactly the same way, if you remove the line use strict;.
Some of my code started breaking, because I had the dirty habbit of declaring a global variable in the main program, and simply reusing that same variable in another do'ed file.
Ah, yes, usually not a good idea. But use strict; won't prevent you from using global variables; it doesn't even prevent you from using cross-scope variables. Nor does using lexical variables implies you are using strict.
I promise that from this day forward, any script that comes in contact with me will have use strict; added to the top.
Yes, and? It's a popular myth that using use strict; makes you a better coder, or improves your code. It doesn't. Your stories implies that your code improves by using lexical variables instead of package variables. That's the important lesson. Not the strict. The latter only helps you to think more carefully when using package variables.

Replies are listed 'Best First'.
Re^2: My confession - I'm now strict-ing...
by moritz (Cardinal) on Jan 25, 2010 at 11:07 UTC
    In particular, any code that runs fine with strict, will continue to run fine, and in exactly the same way, if you remove the line use strict;.

    Most of the time, yes. But not always.

    use strict 'refs'; has a run-time effect. There can be programs that rely on symbolic references throwing an error. A program can rely on such behaviour. 

    use 5.010;

sub ok {
    # remove the "use strict;" and try again...
    use strict;
    local $@;
    eval { $_[0]->[0]; 1 };
}

say ok('foo');

    [download]

    It is unlikely that this code appears like this in production somewhere, but it can very well be hidden somewhere less obvious.

    Perl 6 - links to (nearly) everything that is Perl 6.
[reply]
[d/l]
[select]
Re^2: My confession - I'm now strict-ing...
by Jenda (Abbot) on Jan 25, 2010 at 09:51 UTC
    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.

[reply]
[d/l]
      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.

[reply]
        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.

[reply]
[d/l]
[select]

In Section Meditations