When to use "use strict;"?

[Peng Yu]

I was told to always use "use strict;" in another thread in this
newsgroup. However, I checked Programming Perl. It seems that "use
strict" is not necessary for small program.

In my case, each my perl script is less than 100 lines and would be
reused anywhere else. Do I still need to add "use strict" to my perl
program?

 

[Jürgen Exner]

I was told to always use "use strict;" in another thread in this
newsgroup. However, I checked Programming Perl. It seems that "use
strict" is not necessary for small program.

Please define "necessary". The Perl interpreter doesn't care, in so
fartechnically strict is never necessary. Is it a pretty stupid idea not
to use it? You bet!

In my case, each my perl script is less than 100 lines and would be
reused anywhere else. Do I still need to add "use strict" to my perl
program?

Will you be send to jail if you don't? No.
Will you be criticized when posting snippets of that code and asking for
evaluation? Very likely yes.
Will strict() help you catch and identify stupid programming errors like
typos in variable names? Very likely yes.

Ultimately it is up to you if you want to use the assistance that is
available to you or if you are a hardcore I-don't-need-no-f****-help guy
and prefer to make your coding more difficult than necessary.

Most people prefer to leverage all the help they can get and make their
life easier.

jue

 

[Andrzej Adam Filip]

I was told to always use "use strict;" in another thread in this
newsgroup. However, I checked Programming Perl. It seems that "use
strict" is not necessary for small program.

In my case, each my perl script is less than 100 lines and would be
reused anywhere else. Do I still need to add "use strict" to my perl
program?

"use strict;" helps to detect a lot of "typing mistakes".
You do not need it if you never do such mistakes

P.S.
There are some "tricks" disabled by "use strict;".
Do you use them? No => use "use strict;"

 

[Brad Baxter]

I was told to always use "use strict;" in another thread in this
newsgroup. However, I checked Programming Perl. It seems that "use
strict" is not necessary for small program.

In my case, each my perl script is less than 100 lines and would be
reused anywhere else. Do I still need to add "use strict" to my perl
program?

It doesn't hurt. Always use strict (I do). Well, except
for one-liners (most of the time).

perl -Mstrict -lwe'print "Just another Perl Hacker"'

 

[sreservoir]

"use strict;" helps to detect a lot of "typing mistakes".
You do not need it if you never do such mistakes

P.S.
There are some "tricks" disabled by "use strict;".
Do you use them? No => use "use strict;"

{ no strict qw(what you want); tricks }

 

[Jochen Lehmeier]

Do I still need to add "use strict" to my perl program?

Yes.

 

[RedGrittyBrick]

I was told to always use "use strict;" in another thread in this
newsgroup. However, I checked Programming Perl. It seems that "use
strict" is not necessary for small program.

In my case, each my perl script is less than 100 lines and would be
reused anywhere else. Do I still need to add "use strict" to my perl
program?

I always use strict (except in one-liners).

 

[Charlton Wilbur]

PY> I was told to always use "use strict;" in another thread in this
PY> newsgroup. However, I checked Programming Perl. It seems that
PY> "use strict" is not necessary for small program.

If you need to ask, you aren't experienced enough to know when you don't
need it. And if you are experienced enough to know when you don't need
it, you've also been bitten by stupid bugs often enough to always use it
anyway.


Charlton

 

[sreservoir]

PY> I was told to always use "use strict;" in another thread in this
PY> newsgroup. However, I checked Programming Perl. It seems that
PY> "use strict" is not necessary for small program.

If you need to ask, you aren't experienced enough to know when you don't
need it. And if you are experienced enough to know when you don't need
it, you've also been bitten by stupid bugs often enough to always use it
anyway.

or need to not have it. but that's what lexical pragmata are for.

 

[Graham Drabble]

PY> I was told to always use "use strict;" in another thread
in this PY> newsgroup. However, I checked Programming Perl. It
seems that PY> "use strict" is not necessary for small
program.

If you need to ask, you aren't experienced enough to know when you
don't need it. And if you are experienced enough to know when you
don't need it, you've also been bitten by stupid bugs often enough
to always use it anyway.

I would agree. Does anyone know why so much of the code available from
perldoc (the FAQ and the module docs) is not written so that it can be
used under strict?

I've lost count of the number of times I've copied something in from
the manual, run it and then cursed when strict throws it out.

 

[Jochen Lehmeier]

I've lost count of the number of times I've copied something in from
the manual, run it and then cursed when strict throws it out.

Do you have examples of what you mean?

 

[jl_post]

Do you have examples of what you mean?

"perldoc Getopt::Long" shows this example:

use Getopt::Long;
my $data = "file.dat";
my $length = 24;
my $verbose;
$result = GetOptions ("length=i" => \$length, # numeric
"file=s" => \$data, # string
"verbose" => \$verbose); # flag

Notice that $data, $length, and $verbose are declared with "my", but
$result is not. As a result, if you copy-and-paste this code into a
program that has "use strict;" you'll probably see an error that
$result was not declared.

(Of course, you could argue that $result was declared earlier in
the program, but then you could make that argument for $data, $length,
and $verbose as well.)

I will usually put the "use strict;" and "use warnings;" lines
right into the SYNOPSIS section of the perldocs I write, if only to
instill a sense of "this module works best with 'strict' and
'warnings'" into users who are too inexperienced to know better. To
be honest, I'm not sure if that's a good habit or not (including them
in the perldocs, that is), but I figure if it gets a user to start
using 'strict' and 'warnings' (where they otherwise wouldn't), then
the positive of doing that outweighs the negative.

-- Jean-Luc

 

[Jochen Lehmeier]

Notice that $data, $length, and $verbose are declared with "my", but
$result is not.

(Of course, you could argue that $result was declared earlier in
the program, but then you could make that argument for $data, $length,
and $verbose as well.)

I would say that this kind of example is just that - an example. Or a
specification. It shows how to use the module, but whether some variable
used in the example has a "my" in front of it does not really matter. You
would certainly need to edit the code anyway, since your code will MOST
probably not need a "length", "file", "verbose" parameter. ;-)

I will usually put the "use strict;" and "use warnings;" lines
right into the SYNOPSIS section of the perldocs I write,

I only include the barest necessary code as a "wrapper" around whatever I
want to show. I assume that the reader of some module documentation knows
about strict, warnings, my etc. OTOH, I have no public modules, either,
and know the people who use mine.

My minimum form of POD is usually like this:

=head2 someFunc

($xyz,$abc) = MyModule::someFunc($def,$ghi);

Blablabla ...

=cut

This outputs the "signature" of the function prominently at the top, i.e.,
it tells the user what arguments I expect and what I return (of course, if
the sub is a difficult one, more examples may be added). But whether or
not "my" is in there does not really matter at all. The user is free to
cut&paste that "signature" to avoid some little amount of typing, but he
will usually already have other variable names in place, so the usefulness
of "cut&paste-ready" code seems limited, to me.

be honest, I'm not sure if that's a good habit or not (including them
in the perldocs, that is), but I figure if it gets a user to start
using 'strict' and 'warnings' (where they otherwise wouldn't), then
the positive of doing that outweighs the negative.

Yup, I guess it's philosophical. But I would very seldomly cut&paste some
code from the documentation with the intent of using it without any
further editing - it would in 99% of the cases simply not match my needs
(one notable exception is "perldoc -f localtime" - I frequently cut&paste
that beautiful line which includes the return values ;-) ).

 

[Jürgen Exner]

[...]To
be honest, I'm not sure if that's a good habit or not (including them
in the perldocs, that is), but I figure if it gets a user to start
using 'strict' and 'warnings' (where they otherwise wouldn't), then
the positive of doing that outweighs the negative.

I second your doubts. An explanation for how a specific feature works or
the algorithmic idea for how to solve a specific problem is not the
right place to also introduce (or even just re-enforce) a concept that
has nothing to do with that feature or that algorithm.
Those explanations and code samples should be reduced to the bare
minimum necessary for the issue at hand. Otherwise you are creating a
diversion and confusion: why did the author do this, it appears as if it
has nothing to do with my problem? What am I missing?

jue

 

[John Bokma]

Cut-and-paste (or rather, copy-and-paste) is *always* a mistake when
programming; even if its from examples. You should *read* the example,
*understand* it, and then write your own code using that
understanding.

What an extremistic view point, sigh. I agree that you must understand
the example, but what if the example does *exactly* what you want,
shouldn't you just copy it or does one really have to type it over to be
a real programmer? Oh, my, I just copied an example today. Thankfully it
was Python, and not Perl.