Is pushing strict and warnings still relevant?

[stevieb]

I've been out of using Perl for some time now. After I decided to leave the Network Engineering field, many things changed.

Before I left, I wrote some tutorials et-al (v5.10-ish) and did a preliminary examination report on Perl6, but since, I've found a job where I've been pushed into Python.

My question is, as I dabble here on Perlmonks and some of my older code, I wonder if it is still important to remind people to use the warnings and strictures, or am I getting old?

-stevieb

[jeffa]

I believe so. I almost always preface any sample code i post here with

use strict;
use warnings;

The only "exception" would be my Moose classes, because

use Moose; # automatically turns on strict and warnings

;)

[marinersk]

I believe it is absolutely relevant, and especially where newcomers to the language are concerned.

I've got a metric ton of war stories where use strict;alone accounted for most or all of the solution, and I'm not going to bore you with them here.

The notion that it's "easier" to not use strictures has misled and waylaid far too many people for me to believe otherwise. It might be a tad bit easier for an experienced Perler to write a one-off, but that's about the only place I can justify the risk.

[Anonymous Monk]

I don't know how many PerlMonks SOPW threads you read, but there are still regularly plenty of people whose problems would have been solved or at least made more obvious if they had used strict and warnings. Note that use v5.12; (and up) automatically enables strict. So yes, Use strict and warnings so still very much relevant to wisdom seekers and there's a reason it's the first item on the Basic debugging checklist.

[stevieb]

I check in when I can, as $time + $life permits.

I learned how to program using Perl, and there is no other site on the Internet that holds the formation, loyalty, cleanliness and purity like this one has. Not even some of my past engineering mailing lists have held up.

I did know that v5.12+ use inherently, but I was looking for the current de-facto standard on what I do when I post code samples, by getting info from current loyalists instead of having to go dig for this info. I feel the answer is yes; keep promoting it.

-stevieb

[Anonymous Monk]

I was looking for the current de-facto standard on what I do when I post code samples

Ah, I see. Not sure if there's a "standard"... what I do differs depending on the situation. If the wisdom seeker's troubles would be helped by strict and warnings, or even if they are just new to Perl and post code without the pragmas enabled, they should of course be reminded to enable them (my personal opinion is that they're something that only experienced Perlers should turn off). If I'm posting whole scripts, I include the pragmas along with the shebang line, but when I'm posting short code snippets of a few lines meant for copy & pasting, and which should run the same with or without strict and warnings, I usually test with the pragmas enabled (I invoke Perl as perl -wMstrict) but omit them from the post for brevity. But that's just my approach, other Monks do it differently, but as far as I can tell most people seem to follow the "best practice" of enabling strict and warnings.

[flexvault]

stevieb,

I'm a little confused by your question!

If you are replying to a post, and the use of warnings and strictures would help the OP, then the answer should always be: Yes. I haven't written a script in the past 7-8 years that doesn't have the use statements. And when I come across something prior to that, I always add the statements and deal with any identified problems.

But if the OP is more than a newbie, and the snippet of code looks okay, then your answer/comment should be on the content of the question.

And finally if you are the OP, then I think that all monks should expect the use of warnings and strictures to be already present, and the content has to be looked at in greater detail :-)

Regards...Ed

[sundialsvc4]

I personally think that it is “definitely relevant,” especially because so many of today’s programmers seem to come from one of two backgrounds:   either “anything goes” (JavaScript), or “amazingly-thorough compile-time checks (Java).   The majority seem to come from the latter school, so they expect that the Perl compiler/interpreter does more “compile-time checking” than it actually does.

Personally, I also happen to subscribe to the school of thought that says:   “the computer ought not trust me so much ... that’s what computers are for.”   I like for compilers to catch as many of my inevitable mistakes as they can.   And, I think that most programmers today are conditioned to expect the computer to have done so.   To the extent that we can drill into people’s heads the necessity of specifying these two pragmas, Perl does a reasonably good job.   But if you don’t do this, “Perl trusts you.”   And that, I think, is what gets in the way.   I know that I make “stupid tpyos” all the time, and that I rely on a compiler’s attentiveness.

[einhverfr]

Ummm yes. See this very subtle example of scoping problems that strict helps detect and fix.

[chacham]

Why wouldn't they be? The best time to make a law against a form of activity is when the activity is not being done and is (still) viewed as bad. Waiting until it is a problem is cause for a much harder push that is not always successful.

Noone has to strict warn, and many leave it off for ad-hoc code to test an idea or two. I say it is a good idea to recommend it, just explain why, and let the users make the informed choice when they become of age.