The strict Pragma is a Cultural Marker

For the first several years of the Perl programming language, there was no strict pragma. Variables were effectively global. Barewords were okay. There was little protection against typos—certainly no compiler support for finding them before they caused bugs in your programs.

People wrote a lot of code in those conditions. Even after Perl 5 came out, because strictness of variable declarations, barewords, and references were all optional, people still wrote a lot of code without strict enabled. A lot of that code worked. (As Mark Jason Dominus points out, Perl's strict pragma is not a magic "fix my code" button.)

With that said, I enable strict in every serious program I write, at least every program that's not a one-liner stuck in a shell alias somewhere. The Modern::Perl pseudo-pragma enables strictures, and I encourage novices learning from anything I've written to use it.

For me, it's about limiting risk. I know I make typos. Having perl check that I haven't misspelled a variable or a function name is a tiny little piece of peace of mind that limits the damage I can do from a silly mistake. (I don't find strict reference checking all that useful, because I use soft references very rarely and in very deliberate circumstances.)

For others, it's about helping them to learn. It's difficult enough to learn the semantics of a programming language when you're learning the syntax and idioms too. Yes, use strict; is a small piece of boilerplate magic that a novice might not understand for a while, but a beginner is more likely to make more frequent and more severe beginner mistakes than an experienced programmer. I need a safety net to help me avoid typos, while a beginner needs a safety net to train him or herself to avoid beginner mistakes as a habit.

Habits are important. They're indicators. They're signals. They can be subtle, but when you see a program which starts:

require 'cgi-lib.pl';

... you probably already have a pretty good idea of what you're going to find. (The program may be great, but it may violate some RFCs about the CGI protocol and it's probably not great at all in fact.)

When you see a CPAN distribution with a t/ directory with only one file, t/00-boilerplate.t that's a few dozen bytes in size, you probably have a pretty good idea of the quality and maturity of the code. (The code may be great, but you're going to have to do a lot of work yourself to prove that.)

When you see someone complain that "PERL is unreadable", you probably have a pretty good idea about the kind of code he is referring to. (That code probably starts with require 'cgi-lib.pl';, or at least would be less buggy if it did).

These aren't markers of your worth as a person. They're not markers of the quality or utility of your code. They make no promises of the presence or absence of bugs of intent, and they're not guarantees that there are no bugs of typos. (Would strict be more useful if it could somehow enforce strictness of hash keys?)

The direct and pragmatic value of strict is that it does offer a minimal level of assistance from perl to avoid common behaviors which are often mistakes. They're not necessarily mistakes in very short code, but when you get beyond a couple of hundred lines of code, they're risky. It's easy to overstate its value, even for pedagogic purposes.

It's more difficult to overstate the value of strict as a signifier. It's a symbol. It's an indicator. You're at least making the attempt to avoid silly little errors. The lack of strict oughtn't imply the opposite, but if you're starting out with Perl and using strict, you're at least trying to let the language help you. That's a start.

Like almost anything else in Perl, this oughtn't be a dogmatic rule. The language exists to help you get things done, not to train you to conform to some language designer's theoretical ideals. (But there are theoretical ideals underpinning the design of the language, and you'll have an easier time solving your problems with the language if you design your programs to Perl's strengths.)

Modern Perl: The Book

cover image for Modern Perl: the book

The best Perl Programmers read Modern Perl: The Book.

affiliated with ModernPerl.net

Categories

Pages

About this Entry

This page contains a single entry by chromatic published on November 23, 2013 6:00 AM.

Context and the Comma Operator was the previous entry in this blog.

Icebergs and Software: Dabbling versus Developing is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.


Sponsored by Blender Recipe Reviews and the Trendshare how to invest guide

Powered by the Perl programming language

what is programming?