File Coverage

blib/lib/Perl/Critic/Policy/Tics/ProhibitUseBase.pm

Criterion	Covered	Total	%
statement	17	18	94.4
branch	2	2	100.0
condition			n/a
subroutine	7	8	87.5
pod	4	4	100.0
total	30	32	93.7

use strict;
use warnings;
package Perl::Critic::Policy::Tics::ProhibitUseBase;
# ABSTRACT: do not use base.pm
$Perl::Critic::Policy::Tics::ProhibitUseBase::VERSION = '0.009';
#pod =head1 DESCRIPTION
#pod
#pod   use base qw(Baseclass);
#pod
#pod You've seen that a hundred times, right?  That doesn't mean that it's a good
#pod idea.  It screws with C<$VERSION>, it alters (for the worse) the exceptions
#pod reported by failure-to-require, it doesn't let you call the base class's
#pod C<import> method, it pushes to C<@INC> rather than replacing it, and it uses
#pod and documents interactions with L<fields|fields>, which can lead one to believe
#pod that fields are even remotely relevant to modern (or any!) development of Perl
#pod classes.
#pod
#pod There are a lot of ways around using C<base>.  Pick one.
#pod
#pod =head1 WARNING
#pod
#pod This policy caused a bit of controversy, largely in this form:
#pod
#pod   These behaviors are either correct or can be worked around, and using base.pm
#pod   protects you from the problem of remembering to load prereqs and from
#pod   setting @INC at runtime.
#pod
#pod These are true statements.  My chosen workaround for all these problems is to
#pod I<not use base.pm>.  That doesn't mean it's a good idea for you, or anyone
#pod else.  Heck, it doesn't mean it's a good idea for me, either.  It's just my
#pod preference.  As with all Perl::Critic policies, you should decide whether it's
#pod right for you.
#pod
#pod =cut

use Perl::Critic::Utils;
use parent qw(Perl::Critic::Policy);

my $DESCRIPTION = q{Use of "base" pragma};
my $EXPLANATION = q{Don't use base, set @INC or use a base.pm alternative.};

sub default_severity { $SEVERITY_LOW             }
sub default_themes   { qw(tics)                  }
sub applies_to       { 'PPI::Statement::Include' }

sub violates {
  my ($self, $elem, $doc) = @_;

  return unless $elem->module eq 'base';

  # Must be a violation...
  return $self->violation($DESCRIPTION, $EXPLANATION, $elem);
}

1;

__END__

=pod

=encoding UTF-8

=head1 NAME

Perl::Critic::Policy::Tics::ProhibitUseBase - do not use base.pm

=head1 VERSION

version 0.009

=head1 DESCRIPTION

  use base qw(Baseclass);

You've seen that a hundred times, right?  That doesn't mean that it's a good
idea.  It screws with C<$VERSION>, it alters (for the worse) the exceptions
reported by failure-to-require, it doesn't let you call the base class's
C<import> method, it pushes to C<@INC> rather than replacing it, and it uses
and documents interactions with L<fields|fields>, which can lead one to believe
that fields are even remotely relevant to modern (or any!) development of Perl
classes.

There are a lot of ways around using C<base>.  Pick one.

=head1 WARNING

This policy caused a bit of controversy, largely in this form:

  These behaviors are either correct or can be worked around, and using base.pm
  protects you from the problem of remembering to load prereqs and from
  setting @INC at runtime.

These are true statements.  My chosen workaround for all these problems is to
I<not use base.pm>.  That doesn't mean it's a good idea for you, or anyone
else.  Heck, it doesn't mean it's a good idea for me, either.  It's just my
preference.  As with all Perl::Critic policies, you should decide whether it's
right for you.

=head1 AUTHOR

Ricardo SIGNES <[e-mail]>

=head1 COPYRIGHT AND LICENSE

This software is copyright (c) 2007 by Ricardo SIGNES.

This is free software; you can redistribute it and/or modify it under
the same terms as the Perl 5 programming language system itself.

=cut