Perl Language
Migliori pratiche

Utilizzo di Perl :: Critico

Se desideri iniziare a implementare le migliori pratiche, per te o il tuo team, allora Perl :: Critic è il miglior punto di partenza. Il modulo è basato sul libro Perl Best Practices di Damien Conway e fa un buon lavoro implementando i suggerimenti ivi contenuti.

Nota: dovrei menzionare (e lo stesso Conway dice nel libro) che questi sono suggerimenti. Ho trovato che il libro fornisce un solido ragionamento nella maggior parte dei casi, anche se certamente non sono d'accordo con tutti loro. La cosa importante da ricordare è che, a prescindere dalle pratiche che decidi di adottare, rimani coerente. Più il tuo codice è prevedibile, più facile sarà mantenere.

Puoi anche provare Perl :: Critic tramite il tuo browser su perlcritic.com .

Installazione

cpan Perl::Critic

Questo installerà il set di regole di base e uno script perlcritico che può essere chiamato dalla riga di comando.

Uso di base

Il documento CPAN per perlcritic contiene la documentazione completa, quindi esaminerò solo i casi di utilizzo più comuni per iniziare. L'utilizzo di base è semplicemente chiamare perlcritic sul file:

 perlcritic -1 /path/to/script.pl

perlcritic funziona sia su script che su moduli. Il -1 si riferisce al livello di gravità delle regole che si desidera eseguire rispetto allo script. Ci sono cinque livelli che corrispondono a quanto Perl :: Critic sceglierà il tuo codice.

-5 è il più delicato e avviserà solo su problemi potenzialmente pericolosi che potrebbero causare risultati imprevisti. -1 è il più brutale e si lamenterà di cose tanto piccole quanto il tuo codice è in ordine o no. Secondo la mia esperienza, mantenere il codice conforme al livello 3 è abbastanza buono da tenerlo lontano dal pericolo senza diventare troppo perspicace.

Per impostazione predefinita, qualsiasi errore elencherà il motivo e la gravità dei trigger regola su:

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)

Visualizzazione delle politiche

Puoi vedere rapidamente quali regole vengono attivate e perché utilizzare l'opzione --verbose di perlcritic:

Impostando il livello su 8 mostrerai la regola che ha attivato un avviso:

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)

Mentre un livello di 11 mostrerà i motivi specifici per cui esiste la regola:

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

Codice ignorante

Ci saranno momenti in cui non puoi rispettare una politica Perl :: Critico. In questi casi, puoi inserire commenti speciali, " ## use critic () " e " ## no critic", attorno al tuo codice per far sì che Perl :: Critic li ignori. Aggiungi semplicemente le regole che vuoi ignorare tra parentesi (i multipli possono essere separati da una virgola).

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

Assicurati di avvolgere l'intero blocco di codice o Critica potrebbe non riconoscere l'istruzione ignore.

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

Si noti che ci sono determinate politiche che vengono eseguite a livello di documento e non possono essere esentate in questo modo. Tuttavia, possono essere disattivati ​​...

Creazione di eccezioni permanenti

Usare ## no critic () è bello, ma quando inizi ad adottare gli standard di codifica, probabilmente vorrai fare delle eccezioni permanenti a certe regole. È possibile farlo creando un file di configurazione .perlcriticrc .

Questo file ti consentirà di personalizzare non solo quali criteri vengono eseguiti, ma come vengono eseguiti. Usarlo è semplice come posizionare il file nella tua home directory (in Linux, non so se è lo stesso posto su Windows). Oppure, puoi specificare il file di configurazione quando esegui il comando usando l'opzione --profile :

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

Di nuovo, la pagina perlcritica CPAN ha un elenco completo di queste opzioni. Elencherò alcuni esempi dal mio file di configurazione:

Applica le impostazioni di base:

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

Disabilitare una regola (notare il trattino davanti al nome della politica):

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

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

Modifica di una regola:

# 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+

Conclusione

Correttamente utilizzato, Perl :: Critic può essere uno strumento inestimabile per aiutare i team a mantenere la codifica coerente e facilmente manutenibile, a prescindere dalle politiche di best practice che si utilizzano.