in reply to Trivial style ideas

When I code, I try to make perl as hard on myself as possible, in order to catch bugs early. This is one reason why I, and alot of other people always use strict and -w. I find that when you code consistently in this environment, the amount of errors you produce goes down, as you slowly change your style to be cleaner.

One thing I do is put this at the top of all my code:

#!/usr/bin/perl -w BEGIN { use strict; #Always.. use Carp qw(verbose confess); #die verbosely, with stacktraces $SIG{__WARN__} = \&confess; #die, on warnings }

The main reason behind this is to make sure that there are no uninitialized value warnings, among other things, or else the program won't function at all. I find it forces me to use defined and exists as well before accessing values.

Also, by putting it inside the BEGIN block, I am ensuring it will happen before any other modules load or any other code is executed.

Does anyone think this is going too far, or that it could cause problems? If not, does anyone have any other general suggestions on how to make perl harder on myself?

Update: I have taken tilly's advice, and removed the code, and put it outside of a BEGIN block:

#!/usr/bin/perl -w use strict; use Carp qw(verbose confess); $SIG{__WARN__} = \&confess;

I still prefer to set the warn signal handler to confess, because I want my programs to die when modules or the code itself has unitilialized values or other warnings inside it. I find that it forces me not to ignore small or large problems, as a broken program/module will get fixed before an annoying one. (And you never know when that annoying program could be causing 10x the amount of time to fix than if it was done when the annoyances first started).

Replies are listed 'Best First'.
Re (tilly) 2: Trivial style ideas
by tilly (Archbishop) on Jan 24, 2001 at 17:22 UTC
    Putting strict inside the BEGIN block keeps it from being seen for the whole module. Since use already happens immediately upon parsing the command, there is likewise no win for putting Carp inside the BEGIN block. As for turning warnings into dies, you could inline it like you are doing or create a small pragmatic module for it.

    One problem though. Warnings are added from time to time, so if you inline it there is a real possibility that a future change could hose large portions of your programs. Putting it in the module leaves you just as strict now, but with room to avoid a bad upgrade later. :-)