Is it time for 'use stricter'?

[xdg]

Perhaps it's due to the recent release of TheDamian's book, Perl Best Practices, or maybe there's just something in the air, but perlstyle interest seems to be flourishing. Recent examples include Things I Don't Use in Perl, Perl Best Practices for naming variables and Perl Best Practices (review).

Maybe its time for style to be more than just a recommendation. Inspired by the recent, lengthy debate on the module-authors list about RFC: Test::Stupid, I'm wondering if it's time for a new pragma: 'stricter'.

stricter would use source filtering to check not just for the usual 'vars', 'refs' and 'subs', but for style no-no's as well. Examples of individual options might include:

use stricter 'names';     # no names in MixedCaps
use stricter 'features';  # no ties, lvalue subs or pseudohashes
use stricter 'accessors'; # no accessors that are also mutators
use stricter 'open'       # 3-argument open only
use stricter 'syntax';    # no 'until' or 'unless' or c-style 'for' lo
+ops
use stricter 'whitespace' # no tabs, only spaces
use stricter 'layout';    # must match a perltidy format

As with strict, failure of any code following 'use stricter' to meet the style requirements would cause compilation to fail with an appropriate error message and a pointer to the offending line. Of course, any of these could be turned off within a particular block with an appropriate 'no stricter' line.

It is important that stricter should be easy to subclass to customize style restrictions for particular flavors or projects, e.g. 'use stricter::pbp'. This feature would allow teams of Perl programmers to easily standardize and check their coding practices by simply customizing and adding an appropriate stricter to their modules and scripts.

I think this would be a valuable addition to the Perl pragma family. Don't you?

(If you've read this far and haven't figure out that I mean this in jest, please take a deep breath and walk around in the fresh air a bit -- you're entirely too wound up. Sometimes we need to not take ourselves too seriously.)

Regards,

[holli]

#load modules
use strict;
use stricter 'comments', 2;

#This prints something
print "a";
print "b";
print "c";

...

> perl comment.pl
  Script not adequatly commented at /comment.pl line 7.

:-)

[ysth]

I don't know about you, but I'd require "use stricter 'all'" in code I had to maintain. Including a "use stricter 'PHP'" that makes sure no features are used that don't have a direct PHP equivalent, so we don't have to waste so much money hiring real Perl programmers.

:)

[QM]

That's an interesting list.

However, there are situations that require reverting to no stricter, perhaps more often than you think.

Sure, I hate MixedCase identifiers, but in some shops that's the requirement. (I prefer Mixed_Case over MixedCase, but I want Mixed_Case to mean something special, more than lower_case, but perhaps less emphatically than UPPER_CASE.)

C-style for loops are concise when dealing with complicated indexing, though granted they are just compact syntax for while loops, if more emphatic-looking.

I'll grant unless is not very appealing, but is lazy. However, I like until, because it's often paired up as in do {...} until (). But I suppose it's equivalence with while (not(...)) is what's got everyone agitated.

I think we should tread carefully, so that Perl doesn't suffer more from the shortcomings of Lisp or Pascal (as in "There might be one way to do it in Pascal).

In the end, we'll all have to make our own choices (except those who get their choices handed to them ;)

[diotalevi]

This is already written and it comes with your copy of perl. See B::Lint. There are many things I'd like to add to B::Lint but I haven't taken the time for yet.

[bluto]

That's a great idea. Perhaps I'll start working on...

use stricter 'must halt';
# There's no infinite loops in this code!
...

... though it might take me a while before I upload this to CPAN.

[chester]

Really? It only took me a few minutes to write my version.

...*shifty eyes*

[brian_d_foy]

This is the sort of thing that prompted me to ask Damian about the lilihood for fist fights in the parking lot after work.

Andy Lester has a lint tool for his local requirements, and that's fine, but once you start putting things in the code you have to figure out what to do with third-party modules that don't care for your particular style. :)

[perrin]

I'm sorry to hear this is a joke. I probably would use it.

[Tanktalus]

Personally, I'm anxiously awaiting someone's meditation on "strict considered harmful." ;-)

[cchampion]

Here you have two:

• to strict or not to strict
• Perlmonk's "best pratices" in the real world

However, they were not very popular when they came out.

[leriksen]

Maybe it should be
use style 'Damian'; # use the PBP recommendations...
Other styles could be built and supplied in a plugin style

just a suggestion.

[zby]

I believe one could start this with Perl::BestPractice.

[xdg]

Yup -- that's the way to do it, I think. I wrote "source filter" in the original partly as it was the thing that occurred to me when the joke first came to me and partly to hint that I wasn't being serious. As people started saying "I wish that existed," I realized that to actually do it would need B (or, as diotalevi said, B::Lint) or PPI. And it should really be an external check -- or something easily turned off or commented out for production. You don't really want your CGI script to take 10 seconds to fire up because it's busy checking to see if you wrote q{} instead of ''.

[jthalhammer]

Perl-Critic does exactly that. It's an extensible static source code analyzer based on PPI. It enforces about 60 of Damian's Best Practices, plus a few others. The current interfaces are the  perlcritic command-line and Test-Perl-Critic which runs via test a script. But I could easily see hooking into a source filter that analyzed the code at compile-time.

-Jeff

[nothingmuch]

Non jokingly, Perl 6 will have wonderful support for a general sense of 'use stricter'.

In two words: type inferrence.

If you annotate your code with types, and further annotate subs as inferrable, and use a pragma for this saftey (sounds like a lot, but really isn't), then you get compile time errors for bad usage of data.

Other safety features Perl 6 has been designed with include:

• Better support for exception handling, especially with UNDO blocks, and 'let' variables
• use fatal;
• More complete lexical scopes
• more "serious" object oriented system - the opaque data type, better support for interfaces through roles
So in a sense, yes, it's time for 'use stricter' (optional, ofcourse), but at a level entirely orthogonal to (and an order of magnitude more significant and important than) style.

[Anonymous Monk]

I'll up the ante. I think its high time we had 'use strictest'. No goto, recursion, regex, map, grep, $_, one letter identifiers ($a, etc.), closures, ternary operator, eval (both kinds), anything named one of ("foo", "bar", "baz"), DWIM, nested loops, references, TMTOWTDI, typeglobs, comma operator, exponentiation, bit-shift operators, bit-wise logical operators, xor (either spelling), flip-flop (range) operator, HERE docs, foreach, qw//, sigils, curley braces, and semicolons. Heck, back in my day, all we had were NAND gates, and we were grateful to have even those.

[pileofrogs]

I'd like to see a 'stricter taint'.

It would mark everything as tainted, and expand the scope of things that blow a taint error. For example:

use stricter qw(taint);
use foo qw(frob);
use bar qw(clam);
my $blah = frob("something");
clam($blah);

$blah would be tainted because we don't trust the foo module to return something rational, and clam($blah) would blow an error because we don't trust the bar module, so we don't know what clam does, and we just passed it something tainted.

[Anonymous Monk]

Don't joke like that! :-( I was hoping you had a nice new module, until I read the end. :-(