Perl Language
Best Practices

Perl :: Critic verwenden

Wenn Sie Best Practices für sich selbst oder Ihr Team implementieren möchten, ist Perl :: Critic der beste Ausgangspunkt. Das Modul basiert auf dem Perl Best Practices- Buch von Damien Conway und kann die darin enthaltenen Vorschläge gut umsetzen.

Hinweis: Ich sollte erwähnen (und Conway selbst sagt in dem Buch), dass dies Vorschläge sind. Ich habe festgestellt, dass das Buch in den meisten Fällen eine solide Begründung liefert, obwohl ich mit allen sicherlich nicht einverstanden bin. Es ist wichtig, sich daran zu erinnern, dass Sie unabhängig von den Praktiken, die Sie übernehmen möchten, konsistent bleiben. Je vorhersehbarer Ihr Code ist, desto einfacher ist die Wartung.

Sie können Perl :: Critic auch über Ihren Browser unter perlcritic.com ausprobieren .

Installation

cpan Perl::Critic

Dadurch werden das grundlegende Regelset und ein perlkritisches Skript installiert, das von der Befehlszeile aus aufgerufen werden kann.

Grundlegende Verwendung

Das CPAN-Dokument für Perlkritik enthält eine vollständige Dokumentation. Daher werde ich nur die häufigsten Anwendungsfälle durchgehen, um Ihnen den Einstieg zu erleichtern . Grundlegende Verwendung ist einfach perlcritic für die Datei aufzurufen:

 perlcritic -1 /path/to/script.pl

perlcritic arbeitet sowohl an Skripten als auch an Modulen. -1 bezieht sich auf den Schweregrad der Regeln, die für das Skript ausgeführt werden sollen. Es gibt fünf Stufen, die der Anzahl der Perl :: Critic-Codes entsprechen.

-5 ist am sanftesten und warnt nur vor potenziell gefährlichen Problemen, die zu unerwarteten Ergebnissen führen können. -1 ist das brutalste und wird sich darüber beschweren, dass der Code aufgeräumt ist oder nicht. Nach meiner Erfahrung ist das Einhalten von Code mit Level 3 gut genug, um die Gefahr zu vermeiden, ohne zu hartnäckig zu werden.

Standardmäßig werden bei Fehlern die Gründe und der Schweregrad aufgeführt, unter dem die Regel ausgelöst wird:

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)

Richtlinien anzeigen

Sie können schnell feststellen, welche Regeln ausgelöst werden und warum. Verwenden Sie dazu die Option --verbose von perlcritic :

Wenn Sie die Stufe auf 8 einstellen, wird die Regel angezeigt, die eine Warnung auslöste:

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)

Eine Stufe von 11 zeigt die spezifischen Gründe, warum die Regel existiert:

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

Code ignorieren

Es kann vorkommen, dass Sie eine Perl :: Critic-Richtlinie nicht einhalten können. In diesen Fällen können Sie spezielle Kommentare " ## use critic () " und " ## no critic " um Ihren Code einschließen, damit Perl :: Critic sie ignoriert. Fügen Sie einfach die Regeln, die Sie ignorieren möchten, in die Klammern ein (ein Vielfaches kann durch ein Komma getrennt werden).

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

Stellen Sie sicher, dass der gesamte Codeblock umbrochen wird. Andernfalls erkennt Critic die Ignore-Anweisung nicht.

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

Beachten Sie, dass bestimmte Richtlinien auf Dokumentebene ausgeführt werden und auf diese Weise nicht freigestellt werden können. Sie können jedoch ausgeschaltet werden ...

Dauerausnahmen erstellen

Die Verwendung von ## no kritik () ist schön, aber wenn Sie mit der Einführung von Codierungsstandards beginnen, möchten Sie wahrscheinlich dauerhafte Ausnahmen von bestimmten Regeln machen. Sie können dies tun, indem Sie eine .perlcriticrc- Konfigurationsdatei erstellen.

Mit dieser Datei können Sie nicht nur anpassen, welche Richtlinien ausgeführt werden, sondern auch, wie sie ausgeführt werden. Die Verwendung der Datei ist so einfach wie das Ablegen der Datei in Ihrem Home-Verzeichnis (in Linux ist es nicht sicher, ob es sich um dieselbe Stelle unter Windows handelt). Oder Sie können die Konfigurationsdatei angeben, wenn Sie den Befehl mit der Option --profile ausführen :

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

Die perlkritische CPAN-Seite enthält eine vollständige Liste dieser Optionen. Ich werde einige Beispiele aus meiner eigenen Konfigurationsdatei auflisten:

Grundeinstellungen übernehmen:

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

Deaktivieren Sie eine Regel (beachten Sie den Bindestrich vor dem Richtliniennamen):

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

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

Regel ändern:

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

Fazit

Richtig eingesetzt, kann Perl :: Critic ein unschätzbares Werkzeug sein, das Teams dabei unterstützt, die Codierung konsistent und leicht zu pflegen, unabhängig von den von Ihnen verwendeten Best-Practice-Richtlinien.