Perl Language
Bästa metoder

Använda Perl :: Kritiker

Om du vill börja implementera bästa praxis, för dig själv eller ditt team, är Perl :: Critic det bästa stället att börja. Modulen är baserad på boken Perl Best Practices av Damien Conway och gör ett ganska bra jobb med att genomföra förslagen i den.

Obs: Jag bör nämna (och Conway själv säger i boken) att det här är förslag. Jag har funnit att boken ger en solid resonemang i de flesta fall, även om jag verkligen inte håller med dem alla. Det viktiga att komma ihåg är att oavsett praxis du väljer att anta, förblir du konsekvent. Ju mer förutsägbar din kod är, desto lättare blir det att underhålla.

Du kan också prova Perl :: Kritik genom din webbläsare på perlcritic.com .

Installation

cpan Perl::Critic

Detta kommer att installera den grundläggande regeluppsättningen och ett perlkritiskt skript som kan anropas från kommandoraden.

Grundläggande användning

CPAN-dokumentet för perlcritic innehåller fullständig dokumentation, så jag kommer bara att gå igenom de vanligaste användningsfallen för att komma igång. Grundläggande användning är att helt enkelt ringa perlcritic i filen:

 perlcritic -1 /path/to/script.pl

perlcritic fungerar både på skript och moduler. -1 hänvisar till svårighetsgraden för de regler du vill köra mot skriptet. Det finns fem nivåer som motsvarar hur mycket Perl :: Critic kommer att plocka isär din kod.

-5 är den mest skonsamma och kommer bara att varna för potentiellt farliga problem som kan orsaka oväntade resultat. -1 är den mest brutala och kommer att klaga på saker som är så små som att din kod är snygg eller inte. Enligt min erfarenhet är att hålla koden överensstämmer med nivå 3 tillräckligt bra för att undvika fara utan att bli för persnickety.

Som standard listar alla fel orsaken till och svårighetsgraden som regeln utlöser på:

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)

Visar policyer

Du kan snabbt se vilka regler som utlöses och varför genom att använda perlcritic's - verbose alternativ:

Om du ställer in nivån till 8 visar du regeln som utlöste en varning:

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)

Medan en nivå på 11 visar de specifika skälen till att regeln finns:

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

Ignorera kod

Det kommer att finnas tillfällen då du inte kan följa en Perl :: kritikpolicy. I dessa fall kan du lägga in speciella kommentarer " ## use critic () " och " ## no critic " runt din kod för att få Perl :: Kritiker att ignorera dem. Lägg bara till reglerna som du vill ignorera inom parenteserna (multiplar kan separeras med komma).

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

Se till att packa in hela kodblocket, annars kanske Kritiker inte känner igen ignoreringssatsen.

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

Observera att det finns vissa policyer som körs på dokumentnivå och inte kan undantas på detta sätt. Men de kan stängas av ...

Skapa permanenta undantag

Att använda ## ingen kritiker () är trevligt, men när du börjar anta kodningsstandarder kommer du förmodligen att vilja göra permanenta undantag från vissa regler. Du kan göra detta genom att skapa en .perlcriticrc- konfigurationsfil.

Denna fil låter dig anpassa inte bara vilka policyer som körs, utan hur de körs. Att använda den är lika enkelt som att placera filen i din hemkatalog (i Linux, osäker på om det är samma plats på Windows). Du kan också ange konfigurationsfilen när du kör kommandot med alternativet --profile :

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

Återigen har den perlkritiska CPAN-sidan en fullständig lista över dessa alternativ. Jag kommer att lista några exempel från min egen konfigurationsfil:

Använd grundinställningar:

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

Inaktivera en regel (notera strecket framför policynamnet):

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

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

Ändra en regel:

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

Slutsats

Perl :: Kritiker kan användas på rätt sätt och kan vara ett ovärderligt verktyg för att hjälpa team att hålla deras kodning konsekvent och lätt att underhålla oavsett vilken policy för bästa praxis du använder.