Re: use sloppy ;-)
by Abigail-II (Bishop) on Oct 15, 2003 at 23:50 UTC
|
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 | [reply] [Watch: Dir/Any] |
Re: use sloppy ;-)
by chromatic (Archbishop) on Oct 15, 2003 at 23:24 UTC
|
| [reply] [Watch: Dir/Any] [d/l] |
Re: use sloppy ;-)
by Desdinova (Friar) on Oct 16, 2003 at 04:41 UTC
|
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
| [reply] [Watch: Dir/Any] |
Re: use sloppy ;-)
by revdiablo (Prior) on Oct 15, 2003 at 23:56 UTC
|
| [reply] [Watch: Dir/Any] [d/l] |
Re: use sloppy ;-)
by pg (Canon) on Oct 16, 2003 at 01:33 UTC
|
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.
| [reply] [Watch: Dir/Any] |
Learn from what's out there!
by DentArthurDent (Monk) on Oct 16, 2003 at 12:57 UTC
|
| [reply] [Watch: Dir/Any] |
|
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.)
------
We are the carpenters and bricklayers of the Information Age.
The idea is a little like C++ templates, except not quite so brain-meltingly complicated. -- TheDamian, Exegesis 6
... strings and arrays will suffice. As they are easily available as native data types in any sane language, ... - blokhead, speaking on evolutionary algorithms
Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.
| [reply] [Watch: Dir/Any] [d/l] [select] |
|
| [reply] [Watch: Dir/Any] |
|
|
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
| [reply] [Watch: Dir/Any] |
|
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.
---- I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer
:(){ :|:&};:
Note: All code is untested, unless otherwise stated
| [reply] [Watch: Dir/Any] [d/l] [select] |
Re: use sloppy ;-)
by ambrus (Abbot) on Oct 17, 2003 at 11:56 UTC
|
It's a bad idea. Compare with gcc, where you have to ask for warnings explicitly too. | [reply] [Watch: Dir/Any] |