Perl Language
Mejores prácticas

Utilizando Perl :: Crítico

Si desea comenzar a implementar las mejores prácticas, para usted o su equipo, entonces Perl :: Critic es el mejor lugar para comenzar. El módulo se basa en el libro Perl Best Practices de Damien Conway y realiza un trabajo bastante bueno implementando las sugerencias que se hacen en él.

Nota: Debo mencionar (y el mismo Conway dice en el libro) que estas son sugerencias. He encontrado que el libro proporciona un razonamiento sólido en la mayoría de los casos, aunque ciertamente no estoy de acuerdo con todos ellos. Lo importante a recordar es que, independientemente de las prácticas que decida adoptar, usted permanece consistente. Cuanto más predecible sea su código, más fácil será mantenerlo.

También puede probar Perl :: Critic a través de su navegador en perlcritic.com .

Instalación

cpan Perl::Critic

Esto instalará el conjunto de reglas básicas y un script perlcritic al que se puede llamar desde la línea de comandos.

Uso básico

El documento de CPAN para perlcritic contiene documentación completa, por lo que solo revisaré los casos de uso más comunes para comenzar. El uso básico es simplemente llamar perlcritic en el archivo:

 perlcritic -1 /path/to/script.pl

Perlcritic funciona tanto en scripts como en módulos. El -1 se refiere al nivel de gravedad de las reglas que desea ejecutar en el script. Hay cinco niveles que corresponden a la cantidad que Perl :: Critic separará tu código.

-5 es el más suave y solo advertirá sobre problemas potencialmente peligrosos que podrían causar resultados inesperados. -1 es el más brutal y se quejará de cosas tan pequeñas como que su código esté ordenado o no. En mi experiencia, mantener el código compatible con el nivel 3 es lo suficientemente bueno como para mantenerse fuera de peligro sin ponerse demasiado inquieto.

De manera predeterminada, cualquier falla incluirá la razón y la severidad que la regla activa en:

perlcritic -3 --verbose 8 /path/to/script.pl

Debugging module loaded at line 16, column 1.  You've loaded Data::Dumper, which probably shouln't be loaded in production.  (Severity: 4)
Private subroutine/method '_sub_name' declared but not used at line 58, column 1.  Eliminate dead code.  (Severity: 3)
Backtick operator used at line 230, column 37.  Use IPC::Open3 instead.  (Severity: 3)
Backtick operator used at line 327, column 22.  Use IPC::Open3 instead.  (Severity: 3)

Políticas de visualización

Puede ver rápidamente qué reglas se están activando y por qué utilizando la opción --verbose de perlcritic:

Establecer el nivel en 8 le mostrará la regla que activó una advertencia:

perlcritic -3 --verbose 8 /path/to/script.pl

[Bangs::ProhibitDebuggingModules] Debugging module loaded at line 16, column 1.  (Severity: 4)
[Subroutines::ProhibitUnusedPrivateSubroutines] Private subroutine/method '_sub_name' declared but not used at line 58, column 1.  (Severity: 3)
[InputOutput::ProhibitBacktickOperators] Backtick operator used at line 230, column 37.  (Severity: 3)
[InputOutput::ProhibitBacktickOperators] Backtick operator used at line 327, column 22.  (Severity: 3)

Mientras que un nivel de 11 mostrará las razones específicas por las que existe la regla:

perlcritic -3 --verbose 11 /path/to/script.pl

Debugging module loaded at line 16, near 'use Data::Dumper;'.
  Bangs::ProhibitDebuggingModules (Severity: 4)
    This policy prohibits loading common debugging modules like the
    Data::Dumper manpage.

    While such modules are incredibly useful during development and
    debugging, they should probably not be loaded in production use. If this
    policy is violated, it probably means you forgot to remove a `use
    Data::Dumper;' line that you had added when you were debugging.
Private subroutine/method '_svn_revisions_differ' declared but not used at line 58, near 'sub _sub_name {'.
  Subroutines::ProhibitUnusedPrivateSubroutines (Severity: 3)
    By convention Perl authors (like authors in many other languages)
    indicate private methods and variables by inserting a leading underscore
    before the identifier. This policy catches such subroutines which are
    not used in the file which declares them.

    This module defines a 'use' of a subroutine as a subroutine or method
    call to it (other than from inside the subroutine itself), a reference
    to it (i.e. `my $foo = \&_foo'), a `goto' to it outside the subroutine
    itself (i.e. `goto &_foo'), or the use of the subroutine's name as an
    even-numbered argument to `use overload'.
Backtick operator used at line 230, near 'my $filesystem_diff = join q{}, `diff $trunk_checkout $staging_checkout`;'.
  InputOutput::ProhibitBacktickOperators (Severity: 3)
    Backticks are super-convenient, especially for CGI programs, but I find
    that they make a lot of noise by filling up STDERR with messages when
    they fail. I think its better to use IPC::Open3 to trap all the output
    and let the application decide what to do with it.

        use IPC::Open3 'open3';
        $SIG{CHLD} = 'IGNORE';

        @output = `some_command`;                      #not ok

        my ($writer, $reader, $err);
        open3($writer, $reader, $err, 'some_command'); #ok;
        @output = <$reader>;  #Output here
        @errors = <$err>;     #Errors here, instead of the console
Backtick operator used at line 327, near 'my $output = `$cmd`;'.
  InputOutput::ProhibitBacktickOperators (Severity: 3)
    Backticks are super-convenient, especially for CGI programs, but I find
    that they make a lot of noise by filling up STDERR with messages when
    they fail. I think its better to use IPC::Open3 to trap all the output
    and let the application decide what to do with it.

        use IPC::Open3 'open3';
        $SIG{CHLD} = 'IGNORE';

        @output = `some_command`;                      #not ok

        my ($writer, $reader, $err);
        open3($writer, $reader, $err, 'some_command'); #ok;
        @output = <$reader>;  #Output here
        @errors = <$err>;     #Errors here, instead of the console

Ignorando el código

Habrá ocasiones en que no pueda cumplir con una política de Perl :: Critic. En esos casos, puedes envolver comentarios especiales, " ## use critic () " y " ## no critic ", alrededor de tu código para hacer que Perl :: Critic los ignore. Simplemente agregue las reglas que desea ignorar entre paréntesis (los múltiplos se pueden separar con una coma).

##no critic qw(InputOutput::ProhibitBacktickOperator)
my $filesystem_diff = join q{}, `diff $trunk_checkout $staging_checkout`;
## use critic

Asegúrese de envolver el bloque de código completo o el crítico puede no reconocer la instrucción de ignorar.

## no critic (Subroutines::ProhibitExcessComplexity)
sub no_time_to_refactor_this {
    ...
}
## use critic

Tenga en cuenta que hay ciertas políticas que se ejecutan en el nivel del documento y no pueden ser exentas de esta manera. Sin embargo, se pueden desactivar ...

Creando excepciones permanentes

Usar ## no critic () es bueno, pero cuando comience a adoptar estándares de codificación, es probable que desee hacer excepciones permanentes a ciertas reglas. Puede hacer esto creando un archivo de configuración .perlcriticrc .

Este archivo le permitirá personalizar no solo las políticas que se ejecutan, sino también cómo se ejecutan. Su uso es tan simple como colocar el archivo en su directorio de inicio (en Linux, sin saber si es el mismo lugar en Windows). O bien, puede especificar el archivo de configuración cuando ejecute el comando usando la opción --profile :

perlcritic -1 --profile=/path/to/.perlcriticrc /path/to/script.pl

Una vez más, la página CPAN perlcritic tiene una lista completa de estas opciones. Enumeraré algunos ejemplos de mi propio archivo de configuración:

Aplicar la configuración básica:

#very very harsh
severity = 1
color-severity-medium = bold yellow
color-severity-low = yellow
color-severity-lowest = bold blue

Deshabilite una regla (observe el guión delante del nombre de la política):

# do not require version control numbers
[-Miscellanea::RequireRcsKeywords]

# pod spelling is too over-zealous, disabling
[-Documentation::PodSpelling]

Modificar una regla:

# do not require checking for print failure ( false positives for printing to stdout, not filehandle )
[InputOutput::RequireCheckedSyscalls]
    functions = open close

# Allow specific unused subroutines for moose builders
[Subroutines::ProhibitUnusedPrivateSubroutines]
private_name_regex = _(?!build_)\w+

Conclusión

Utilizado correctamente, Perl :: Critic puede ser una herramienta invaluable para ayudar a los equipos a mantener su codificación constante y fácil de mantener, sin importar las políticas de mejores prácticas que emplee.