Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery

Is it time for 'use stricter'?

by xdg (Monsignor)
on Aug 24, 2005 at 14:49 UTC ( #486213=perlmeditation: print w/replies, xml ) Need Help??

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.)



Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

Replies are listed 'Best First'.
Re: Is it time for 'use stricter'?
by holli (Abbot) on Aug 24, 2005 at 16:22 UTC
    #load modules use strict; use stricter 'comments', 2; #This prints something print "a"; print "b"; print "c";
    > perl Script not adequatly commented at / line 7.

    holli, /regexed monk/
Re: Is it time for 'use stricter'?
by ysth (Canon) on Aug 24, 2005 at 15:31 UTC
    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.


Re: Is it time for 'use stricter'?
by QM (Parson) on Aug 24, 2005 at 16:06 UTC
    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 ;)

    Quantum Mechanics: The dreams stuff is made of

Re: Is it time for 'use stricter'?
by diotalevi (Canon) on Aug 24, 2005 at 17:31 UTC
    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.
Re: Is it time for 'use stricter'?
by bluto (Curate) on Aug 24, 2005 at 16:43 UTC
    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.

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

      ...*shifty eyes*

Re: Is it time for 'use stricter'?
by brian_d_foy (Abbot) on Aug 25, 2005 at 05:31 UTC

    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. :)

    brian d foy <>
Re: Is it time for 'use stricter'?
by perrin (Chancellor) on Aug 24, 2005 at 19:27 UTC
    I'm sorry to hear this is a joke. I probably would use it.

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

Re: Is it time for 'use stricter'?
by leriksen (Curate) on Aug 25, 2005 at 00:43 UTC
    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. is better to be approximately right than precisely wrong. - Warren Buffet

Re: Is it time for 'use stricter'?
by zby (Vicar) on Aug 25, 2005 at 07:04 UTC

      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 ''.


      Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

        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.


Re: Is it time for 'use stricter'?
by nothingmuch (Priest) on Aug 27, 2005 at 02:12 UTC
    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.

    zz zZ Z Z #!perl
Re: Is it time for 'use stricter'?
by Anonymous Monk on Jan 13, 2006 at 16:07 UTC
    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.
Re: Is it time for 'use stricter'?
by pileofrogs (Priest) on Jan 14, 2006 at 18:43 UTC

    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.

Re: Is it time for 'use stricter'?
by Anonymous Monk on Aug 25, 2005 at 19:31 UTC
    Don't joke like that! :-( I was hoping you had a nice new module, until I read the end. :-(

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://486213]
Front-paged by neniro
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (2)
As of 2023-12-10 08:09 GMT
Find Nodes?
    Voting Booth?
    What's your preferred 'use VERSION' for new CPAN modules in 2023?

    Results (39 votes). Check out past polls.