There are a few excellent Perl programmers who don't care for strict. However, most seem prefer it because it prevents silly tyops (sic) and all manner of poor programming constructs. There are many reasons why you don't want to use strict, but from what I can see from the average Perl programmer's work, these situations are the exception rather than the rule. One problem with failing to use strict stems from all variables being global. The larger the program, the more likely problems will arise from misspelled globals, globals being munged in unexpected places or a programmer simply forgetting what the globals are for.

Much of the problem with globals can be solved merely with the vars pragma.

#!/usr/bin/perl
$foo = 'bar';
$baz = 'qux';
[download]

The above code will not run under strict. You have a couple of options. One, that I've seen used far too often is prepending the package name.

#!/usr/bin/perl
use strict;
$main::foo = 'bar';
$main::baz = 'qux';
[download]

While having use strict; at the top of your code looks nice, one of the finest benefits of strict is lost: prevention of typos.

#!/usr/bin/perl
use strict;
$main::foo = 'bar';
$main::baz = 'qux';
$main::foo .= $main::bza;
[download]

The vars pragma will catch this:

#!/usr/bin/perl
use strict;
use vars qw/ $foo $baz /;
$foo = 'bar';
$baz = 'qux';
$foo .= $bza;
[download]

Now we get a compile time warning that $bza requires an explicit package name. This doesn't solve all of the problems, but it's a nice start.

But what do we do about globals declared in other packages? From what I can tell, you can't use our or vars for globals in another package. Personally, I wouldn't care for that if I could do that because I think it obscures what's going on.

If it's an object-oriented module, we could subclass it and write get and set methods for the globals. That's what I did with CGI::Safe for $CGI::DISABLE_UPLOADS and $CGI::POST_MAX (to be fair, I only wrote a set method and that was at Lincoln Stein's request). This is a nice, clean method, but it doesn't work if you can't inherit.

Another way of dealing with that is to tie a variable to the global and just use the new variable. This is a fairly universal solution and doesn't have any expectation that the global(s) in question are in an OO module. However, like the above solution, it seems like a lot of work for minimal gain.

Neither of these solutions seem practical unless there are a lot of globals to worry about. Is there an easy solution to this? Is there too little return on the work invested? Naturally, with proper programming, this is not a problem that will crop up often, but I'm dealing with a lot of legacy code here that we're slowly working the kinks out of and I think a clean solution would be nice.

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.