Should I use common::sense or just stick with `use strict` and `use warnings`?

Question

I recently installed a module from CPAN and noticed one of its dependencies was common::sense, a module that offers to enable all the warnings you want, and none that you do

Answer 1

Many of peoples argues in a comments with what if the MP changes, it will break your code. While this can be an real threat, here is already MUCH things what are changes over time and break the code (sometimes after a deprecation cycle, sometimes not...).

Some other modules changed the API, so breaks things, and nobody care about them. E.g. Moose has at least two things what are deprecated now, and probably will be forbidden in some future releases.

Another example, years ago was allowed to write

for $i qw(some words)

now, it is deprecated. And many others... And this is a CORE language syntax.

Everybody survived. So, don't really understand why many of people argues againist helper modules. When they going to change, (probably) here will be a sort of deprecation cycle... So, my view is:

• if you write programs to yourself, use any module you want ;)
• if you write a program to someone, where someone others going to maintnanece it, use minimal nonstandard "pragma-like" modules (common::sense, modern::perl, uni::perl etc...)
• in the stackoverflow questions, you can safely use common::sense or Modern::Perl etc. - most of users who will answer, your questions, knows them. Everybody understand than it is easier to write use 5.010; for enable strict, warnings and fearures with 10 chars as with 3 lines...

Answer 2

There is one bit nobody else seems to have picked up on, and that's FATAL in the warnings list.

So as of 2.0, use common::sense is more akin to:

use strict; 
use warnings FATAL => 'all'; # but with the specific list of fatals instead of 'all' that is 

This is a somewhat important and frequently overlooked feature of warnings that ramps the strictness a whole degree higher. Instead of undef string interpolation, or infinite recursion just warning you and then keeping on going despite the problem, it actually halts.

To me this is helpful, because in many cases, undef string interpolation leads to further more dangerous errors, which may go silently unnoticed, and failing and bailing is a good thing.

Answer 3

While I like the idea of reducing boiler-plate code, I am deeply suspicious of tools like Modern::Perl and common::sense.

The problem I have with modules like this is that they bundle up a group of behaviors and hide behid glib names with changeable meanings.

For example, Modern::Perl today consists of enabling some perl 5.10 features and using strict and warnings. But what happens when Perl 5.12 or 5.14 or 5.24 come out with great new goodies, and the community discovers that we need to use the frobnitz pragma everywhere? Will Modern::Perl provide a consistent set of behaviors or will it remain "Modern". If MP keeps with the times, it will break existing systems that don't keep lock-step with its compiler requirements. It adds extra compatibility testing to upgrade. At least that's my reaction to MP. I'll be the first to admit that chromatic is about 10 times smarter than me and a better programmer as well--but I still disagree with his judgment on this issue.

common::sense has a name problem, too. Whose idea of common sense is involved? Will it change over time?

My preference would be for a module that makes it easy for me to create my own set of standard modules, and even create groups of related modules/pragmas for specific tasks (like date time manipulation, database interaction, html parsing, etc).

I like the idea of Toolkit, but it sucks for several reasons: it uses source filters, and the macro system is overly complex and fragile. I have the utmost respect for Damian Conway, and he produces brilliant code, but sometimes he goes a bit too far (at least for production use, experimentation is good).

I haven't lost enough time typing use strict; use warnings; to feel the need to create my own standard import module. If I felt a strong need for automatically loading a set of modules/pragmas, something similar to Toolkit that allows one to create standard feature groups would be ideal:

use My::Tools qw( standard datetime SQLite );

or

use My::Tools;
use My::Tools::DateTime;
use My::Tools::SQLite;

Toolkit comes very close to my ideal. Its fatal defects are a bummer.

As for whether the choice of pragmas makes sense, that's a matter of taste. I'd rather use the occasional no strict 'foo' or no warnings 'bar' in a block where I need the ability to do something that requires it, than disable the checks over my entire file. Plus, IMO, memory consumption is a red herring. YMMV.

update

It seems that there are many (how many?) different modules of this type floating around CPAN.

• There is latest, which is no longer the latest. Demonstrates part of the naming problem.
• Also, uni::perl which adds enabling unicode part of the mix.
• ToolSet offers a subset of Toolkit's abilities, but without source filters.
• I'll include Moose here, since it automatically adds strict and warnings to the calling package.
• And finally Acme::Very::Modern::Perl

The proliferation of these modules and the potential for overlapping requirements, adds another issue.

What happens if you write code like:

use Moose;
use common::sense;

What pragmas are enabled with what options?