use sloppy ;-)

[cLive ;-)]

Just had a thought. Since we hit people with a pointy stick that don't 'use strict', wouldn't it be a good idea to have strict and warnings pragmas on by default, and rename the 'no warnings' and 'no strict' pragmas to use sloppy and use very sloppy, thereby making good practice the norm.

Or perhaps, at the very least, add a flag to make strict and warnings mandatory at compile time as a way (say) of enforcing good practice throughout a company? (Or maybe you already can and my ignorance is shining through here? :)

.02

cLive ;-)

[Abigail-II]

Very bad idea, IMO. While using 'strict' and 'warnings' is often a good idea, slavishly turning them on no matter what is a bad idea. Perl too often gets warnings wrong, and with strictness turned on, you can't do a lot of useful things.

Only turn on things you know how and when to turn off.

Having said that, if you really want to play 'nasty programming lead', set "PERL5OPT='-Mstrict -Mwarnings'" in whatever config file(s) in /etc that's appropriate for your OS.

Abigail

[chromatic]

That would certainly make one-liners longer:

perl -Msloppy -e '...'

[Desdinova]

I do agree that there are some serious pitfalls with this. Realistlly this better handled through proper code reviews within the company, make 'use strict;' a standard, then leave it up to the people coding to explain why they didn't. Sencondly this would work if you have no perl code in use right now, but you enable this globally any currently 'bad' script will cease working, not a fun thing to walk into the next day.

On lighter note you could use this

[revdiablo]

Maybe use sloppy; could be more like Acme::Inline::PERL?

8^)

[pg]

I believe, what will happen then is people will start to 'use sloppy', as people can always interprete a negative word positively, and start to make it a fasion. (So this does not discourage people)

Don't get me wrong, I support use warnings and strict.

Language is evolving, especially in the cyber-world, very fast.

[DentArthurDent]

In most other compiled languages, you get all errors and some number of warnings at compile time, and then you have the ability to vary the number of warnings.

As I understand things (never used it), strict causes things that wouldn't otherwise have been errors to be errors and is recommended. I think this is a bad idea. Better to have anything that is that dangerous always be an error. Ask yourself: is it an error or isn't it?

Warnings on the other hand, should have variable levels. Pick a few things that generally are bad bad errors but might be ok and use that as a starting point, then leave it up to the user to turn them all on or all off.

Can you tell I code more in C than Perl? :-)

[dragonchild]

strict deals with things that almost always aren't what you want to do. But, strict robs the ability of the experienced developer to do cool things. This is why no strict; and no warnings 'blah' are there. All my Exporter modules have the following at the top:

package Something::Or::Other;

use strict;
use warnings
no warnings 'once';

# Stuff here

1;

The 'once' item is one I don't want in a values repository. But, I don't use the no warnings 'once' item in my scripts because I should be using all my variables more than once. (If it's a repository, it should be in an Exporter module.)

The same goes double with strict. The only strict item I ever turn off is 'refs', but I turn it off a lot, in specific situations when I really do have to use soft references. But, I know why I'm using soft references and I am planning on using soft references. Everywhere else, I'm too lazy to keep track, so I want the compiler to keep track for me, so I turn strict on.

Soft references are dangerous in every situation ... just in most of them. So, if they were always errors, a lot of code wouldn't work. (Like, the code in Exporter, the most commonly used non-pragma module in Perl.)

[DentArthurDent]

So is the point of strict, then, to take the rope out of the hands of a programmer so that they can't hang themselves? I guess there's a place for that. I withdraw my objection. :)

[Abigail-II]

All use strict does is make the Perl compiler more like a C compiler: picky. I'd expect people with a C background to embrace 'strict' quicker than people coming from a shell background (or people with no background in programming at all).

Abigail

[hardburn]

Better to have anything that is that dangerous always be an error. Ask yourself: is it an error or isn't it?

This code is an error under strict 'refs':

foreach my $field (qw( foo bar baz)) {
    *$field = sub { 
        my $self = shift;
        $self->{$field} = shift if @_;
        $self->{$field};
    };
}

This is an incredibly great way to create accessors/mutators for an object in the simplist and most common case. It makes it easy to create new accessors/mutators, and is very memory-efficent (since there is actually only one subroutine in memory that handles many different cases).

OTOH, the following also won't work under strict 'refs':

use CGI qw(:all);
my @names = param();
foreach my $name (@names) {
    $$name = param($name);
}

The fact that the above doesn't work under strict 'refs' is a good thing. It would allow any parameters passed to the CGI to clobber the values of existing scalars in the namespace. (This is based on a real example I saw in a SoPW a while back by a well-meaning but obviously inexperianced CGI programmer).

Thus, a new user should always use strict to catch potential errors, but an experianced coder will know when it's OK to shut it off.

[ambrus]

It's a bad idea. Compare with gcc, where you have to ask for warnings explicitly too.