/usr/local/bin/perl
use strict;
use warnings;
use Data::Dumper;
[download]

In the past three months I have started adding use Class::DBI to the list since I am doing a contract that uses an enormous set of Oracle database tables, and every time I turn around I find another table that needs its Object.

In my editor I have a macro that inserts:

#! perl -slw
use strict;
[download]

And that's how I start all my new Perl scripts. Anything else gets added as and when I need it.

On the other hand, in my REPL, which is where I do the majority of my trail&error coding, I have a bunch of things including:

use threads;
use threads::shared;
use Data::Dump qw[ pp ];
use List::Util qw[ min max sum reduce ];
use LWP::Simple;
use XML::Simple;
use GD;
[download]

It also has a bunch of small subs that I use commonly: rgb2n(), n2rgb(), uniq(), rndStr() and others. But both lists tend to change as I encounter different requirements.

I also experimented with use 5.010 (for say) for a little while, but I still use a 32-bit perl5.8.9 sufficiently frequently (because more of CPAN is available via PPM for that build than my 64-bit 5.10 installation), but the inability to use scripts that contain 5.010 with that build put me off.

strict and warnings were pretty much my mainstay since Perl5 was introduced.

use feature got a bit of look in while on 5.10 but I didn't use that for very long.

use 5.12.x has an an implicit use strict (actually, any version > 5.11) and includes all the features so now I just use:

use 5.12.0;
use warnings;
[download]

strict and warnings were pretty much my mainstay since Perl5 was introduced.

Hard for that to actually have been the case since warnings.pm wasn't invented until Perl 5.006.

- tye        

I have been adding use warnings; to the top of my code as a standard practice for about a decade.

My post was not intended as some sort of definitive historical commentary.

To head off any similar comments regarding the strict pragma: perlhist shows the first Perl5 as 5.000alpha1 1993-Jul-31. I make no claims that I used that specific version nor that the strict pragma was available in that version.

I'm reasonably certain that "use" was introduced in a Perl5 version so I wouldn't have "use"d anything in any Perl version prior to that.

-- Ken

use strict;
use warnings;
[download]

I've experimented with larger boilerplates. But then I found myself more often than not deleting lines.

mjscott2702:

Currently, the only thing common to all my programs is:

#!/usr/bin/perl
use strict;
use warnings;
[download]

You didn't ask about comments, but I also add a comment block like the following just before the use pragmata:

#
#       scriptname.pl <args description>
#
#       Brief description of programs and arguments
#
# YYYYMMDD: Latest change(s)
# YYYYMMDD: Prior change(s)
# ...
# YYYYMMDD: original version
[download]

From there, it depends on what type of script I'm writing. My most commonly used modules are (roughly in order):

use DBI;
use Data::Dumper;
use Spreadsheet::WriteExcel;
use File::Find; 
use Net::FTP;
use Mime::Lite;
use Spreadsheet::ParseExcel;
[download]

I'm trying to start getting in the habit of using (even though I should upgrade to 5.12):

use 5.10.0;
[download]

...roboticus

You didn't ask about comments, but I also add a comment block like the following

My boilerplate uses POD instead of comments for usage information. That gives me a manpage for free using perldoc.

toolic:

++ That's a good suggestion! I think I'll have to update my template to do that, too.

...roboticus

use strict; is pretty ubiquitous but I don't even use warnings; all that much (I use "#!/usr/bin/perl -w" a lot).

The point of 'use warnings' was that somebody got annoyed with some module where the author didn't test that their module code didn't generate warnings. But it is certainly less than perfect on a lot of other points.

One big problem is that a lot of warnings are generated more by data than by code. For example:

use warnings;
use NotMy::Module qw< setsomestring >;

my $input= <STDIN>;
setsomestring( $input );
[download]

If NotMy/Module.pm doesn't contain use warnings;, then my use warnings; above is powerless to tell me that I've failed to check for an end-of-file and have just passed undef to a function that isn't meant to deal with undef (and just acted like I passed it an empty string which is a bug and something I wanted to know about).

The converse is also a problem:

no warnings;
use NotMy::Module qw< setsomestring >;

my $input= <STDIN>;
setsomestring( $input );
[download]

Here, "no warnings;" means that I'm coding in a mode where I don't want to have to write a bunch of obnoxious trivia like $input= '' if ! defined $input; all over the place and I actually want end-of-file to result in setsomestring() acting like I gave it an empty string. And yet, the new version of NotMy/Module.pm says use warnings; so I still get annoyed by those way-too-common "undef" warnings.

The better (but in-a-perfect-world) solution for the original problem of people who don't test whether their modules generate warnings (even when never given data by the module user that could be blamed for the warning) would actually be to get such module authors to mark their modules with no warnings;. That requires a perfect world because people who don't care about warnings aren't likely to insert no warnings; for the sake of the rest of us.

Luckily for me, the ubiquity of 'use warnings' in the hive mind means that I almost never run into the original problem these days. So my Perl scripts tend to start with "#!/usr/bin/perl -w" and not to 'use warnings'. If I find a warning-generating module, then I deal with that, but I rarely have to.

My modules tend to also not 'use warnings' but my module test scripts also start with #!/usr/bin/perl -w so I try to make sure that my modules don't generate warnings. But I let the users of my modules decide whether or not they want to get warnings when they use my modules.

(But, no, that isn't a perfect solution, either.)

I also typically do a "perl -wc" check on the script to identify issues between the keyboard and chair. However, I usually have a use warnings statement in the code itself, which complains a lot with data-related issues e.g. string concatenation with un-initialised values.

So, given that I perform the integrity check on the script first, is including this pragma as a matter of habit actually doing anything for me, other than generating lots of data-related warnings?

Obviously, there ARE situations when you want to get these warnings, depending on the situation, but I'm leaning towards not including by default - or maybe, like diagnostics, using it when initially testing out the script, but then comment it out?

Obviously, there ARE situations when you want to get these warnings,

Just to be clear, I usually use #!/usr/bin/perl -w (as the first line of each script) which means that I get more warnings than I would if I used use warnings;.

Users of a script usually don't have many ways of giving the script undefined values so the line between "script user" and "script" is not the same as the line between between "module user" and "module" with regard to warnings. If I test a script well, then I usually won't leave it up to the script user to launch via "perl -w ..." in order to get warnings.

However, for scripts that get run other than by other either developers or IT workers, I do indeed sometimes leave warnings turned off when the script is deployed. Warnings seen by a non-technical user or written to a Production log file are very often worse than useless. The lower the odds of "the warning making it back to a developer along with sufficient information for the cause of the warning to be identified so the code can be fixed to eliminate the warning (and perhaps a bug that the warning detected)", the less value there is to leaving warnings enabled.

- tye        

use warnings FATAL => 'all';
use strict;
#use diagnostics;
[download]

• By default, I want warnings to be promoted to errors.
• diagnostics is commented out so that it's easy to remember to enable it when needed (but then I have to remember to comment it back out).

I have Data::Dumper as an editor macro/bindkey so I can slap it down whenever and wherever I need it. Other dumpers may have superior features, but this is the only Core module and, therefore, it's most portable.

use Data::Dumper; $Data::Dumper::Sortkeys=1; print Dumper(\%@foo);
[download]

For a quick script I whip up to do something one time:

use strict;
use warnings;
[download]

For anything more:

use strict;
use warnings;
use Getopt::Long qw(:config no_ignore_case); #bundling
use Pod::Usage;
[download]

... and anything else needed for the script (eg: IO::Socket for networking).

I have a large boilerplate which includes everything I tend to use (CGI, URI, Moose, XML::LibXML, WWW::Mechanize, Path::Class, JSON, YAML, etc, etc, etc) because yanking a paragraph is two keystrokes while adding a few modules plus __PACKAGE__->meta->make_immutable; and __DATA__ can be a couple hundred easy.

use strict;
use warnings;
use 5.012;
[download]

For OO-scripts, I add

use Any::Moose;
[download]

For Modules:

use strict; use warnings; use re 'taint';
[download]

For Scripts:

use strict; use warnings; use 5.010;
use Getopt::Long qw/:config bundling/;
[download]

Now, there are many others that I use very frequently, but these are the only ones that make it into my template.

What I usually use is

# vim:columns=80:ts=4:sw=4:shiftround:filetype=perl
use strict;
use warnings;
use feature     qw( :5.10 );
use Carp;
[download]

Most of the time I'm working on older boxes (RH7.2 anyone?) so I delete the feature pragma and stick to 5.6 era syntax. But for my own stuff I try to use something a bit more modern.

And my list of  use statements is always longer than this. Basics like Cwd, File::Basename, and Data::Dumper pop up pretty regularly, as does Moose::* but they are on a case-by-case basis.

- doug

really depends on what you use perl to do. if you use TK consistently I'd expect to see TK modules used, or if you're writing a lot of CGI then that's what you'd see.

Not that I'm any expert (far from it), but Me personally, I do a lot of sysadmin/file manipulation and goofing around with files. So I have an abnormally large number of scripts with the following modules in use... also, since I am cpan limited I don't generally use modules that I can't get with the base install... which makes life a pain, but it still beats other programming languages...

use Getopt::Long qw(:config no_ignore_case bundling); #or some variati
+on of this.
use Cwd; # I like to keep track of where I started before cd'ing
use File::Basename qw(fileparse); 
use File::stat;
use File::Find; #love this guy 
use Time::gmtime; #for timestamps, etc
use Time::Local; #time's easy to manip if it's a single scalar
use File::Copy; #somewhat DOS/Linux portable (crippled) copy 
use Carp;
use constant CONSTANTNAME => Value; # der...
use Tie::IxHash; #it's slow, but sometimes you need an ordered hash
use File::Compare; #somewhat portable file diff, truthfully laziness u
+sually wins and I usually just call diff as a system call...
[download]