in reply to Strict and warnings: which comes first?

I usually make those the first two non-comment non-blank lines in the file; and I put use strict; first as a matter of aesthetic taste — that both puts them in alphabetical order and gives a nice visual lead towards the right, where the later use statements are likely to end, since most module names are longer than warnings.


use strict; use warnings; use Storable;

Some very useful modules break this pattern:

use strict; use warnings; use DBI; use Tk;

Replies are listed 'Best First'.
Re^2: Strict and warnings: which comes first?
by tobyink (Canon) on Nov 08, 2019 at 12:47 UTC

    I usually put a use VERSION line before them. Most of my modules start off with something like:

    use 5.008; use strict; use warnings;

    ... before even the package statement.

      You are right: I think of package as part of the file header, so it goes in the very first line in a module, like the #! line in a script. I think that most of my code would probably run under 5.6, so my scripts generally lack use VERSION. I may need to see about changing that. :-)

        Since Perl 5.12, package has started to become more interesting. You can do stuffs like:

        use v5.16; use strict; use warnings; package Foo::Bar 1.2 { ...; }

        Although the extended syntax for package doesn't need feature or a use VERSION line to enable it, it seems like a good idea to put the use VERSION before it rather than after, so people with older Perls get an error message about their Perl being too old, instead of an error message about being unable to parse the package statement.

        And even in cases where I'm supporting older Perls, I keep all that stuff before package.

        Sometimes I'll also use modules before package if I know I'm not importing anything into my namespace from them, like:

        use v5.16; use strict; use warnings; use Scalar::Util (); package Foo::Bar 1.2 { ...; my $addr = Scalar::Util::refaddr($ref); # use fully-qualified nam +e because not imported }
      In my environment, I prefer to specify 'feature' rather than 'version' in part because it is much easier to specify correctly. When a module fails due to compatibility issues, 'feature' helps a maintenance programmer modify the module for an older perl. (If he choses to upgrade perl, he will probably upgrade to the newest version and not care about what is the oldest one he can get away with.) I do understand that 'version' is required by many development tools. That does not apply to me - at least not yet.

        There are a bunch of features that doesn't enable, such as //, package NAME { BLOCK }, etc. Not that use VERSION enables them either; you just need a high enough version of Perl.