Warum lehnt Perl :: Critic die Verwendung von shift zum Auffüllen von Unterprogrammvariablen ab?

Question

In letzter Zeit habe ich beschlossen, Perl::Critic häufiger auf meinem Code zu verwenden. Nachdem ich nun seit fast 7 Jahren in Perl programmiert habe, bin ich schon lange mit den meisten Best Practices von Perl vertraut, aber ich weiß, dass es immer noch Raum für Verbesserungen gibt. Eine Sache, die mich jedoch nervt ist die Tatsache, dass Perl::Critic nicht gefällt, wie ich @ _ für Unterprogramme entpacke. Als Beispiel:

sub my_way_to_unpack { 
    my $variable1 = shift @_; 
    my $variable2 = shift @_; 

    my $result = $variable1 + $variable2; 
    return $result; 
} 

Dies ist, wie ich es immer getan habe, und wie seine auf beiden PerlMonks und Stack-Überlauf diskutiert worden ist, seine not necessarily evil entweder.

Ändern der Codeausschnitt oben ...

sub perl_critics_way_to_unpack { 
    my ($variable1, $variable2) = @_; 

    my $result = $variable1 + $variable2; 
    return $result; 
} 

... funktioniert auch, aber ich finde es schwerer zu lesen. Ich habe auch Damian Conways Buch Perl Best Practices gelesen und ich verstehe nicht wirklich, wie mein bevorzugter Ansatz zum Entpacken unter seinen Vorschlag fällt, @_ direkt zu verwenden, wie Perl::Critic impliziert. Ich habe immer den Eindruck, dass Conway spricht über Bösartigkeit wie:

sub not_unpacking { 
    my $result = $_[0] + $_[1]; 
    return $result; 
} 

Das obige Beispiel ist schlecht und schwer zu lesen, und ich würde nie die Ansicht, dass der Produktionscode in einem Stück zu schreiben.

Also kurz gesagt, warum Perl::Critic meinen bevorzugten Weg schlecht betrachten? Mache ich wirklich ein abscheuliches Verbrechen, indem ich die Schicht auspacke?

Wäre das etwas, das andere Leute als ich denken sollten mit den Perl::Critic Betreuer aufgewachsen sein?

Answer 1

Die einfache Antwort ist, dass Perl :: Critic PBP hier nicht folgt. Die Buch explizit besagt, dass die Schicht Idiom ist nicht nur akzeptabel, aber ist in einigen Fällen tatsächlich bevorzugt.

Answer 2

Es ist wichtig, daran zu denken, dass viele der Sachen in Perl Best Practices nur die Meinung eines Kerls darüber ist, was am besten aussieht oder am einfachsten zu arbeiten ist, und es spielt keine Rolle, ob man es anders macht. Damian sagt das im einführenden Text des Buches. Das ist nicht zu sagen, es ist alle so - es gibt viele Dinge in dort, die absolut notwendig sind: mit strict, zum Beispiel.

So wie Sie Ihren Code schreiben, müssen Sie selbst entscheiden, was Ihre eigenen Best Practices sein werden, und die Verwendung von PBP ist so gut wie ein Ausgangspunkt. Bleiben Sie dann mit Ihren eigenen Standards konsistent.

Ich versuche, die meisten Sachen in PBP zu folgen, aber Damian kann meine Subroutine-Argument shift s und meine unless es, wenn er sie aus meinen kalten, toten Fingerspitzen pries.

Wie bei Critic können Sie auswählen, welche Richtlinien Sie erzwingen möchten, und sogar Ihre eigenen erstellen, wenn sie noch nicht existieren.

Answer 3

Das Ausführen perlcritic mit --verbose 11 erläutert die Richtlinien. Es sieht jedoch nicht so aus, als ob diese beiden Erklärungen auf Sie zutreffen.

 
Always unpack @_ first at line 1, near 
'sub xxx{ my $aaa= shift; my ($bbb,$ccc) = @_;}'. 
    Subroutines::RequireArgUnpacking (Severity: 4) 
    Subroutines that use `@_' directly instead of unpacking the arguments to 
    local variables first have two major problems. First, they are very hard 
    to read. If you're going to refer to your variables by number instead of 
    by name, you may as well be writing assembler code! Second, `@_' 
    contains aliases to the original variables! If you modify the contents 
    of a `@_' entry, then you are modifying the variable outside of your 
    subroutine. For example: 

     sub print_local_var_plus_one { 
      my ($var) = @_; 
      print ++$var; 
     } 
     sub print_var_plus_one { 
      print ++$_[0]; 
     } 

     my $x = 2; 
     print_local_var_plus_one($x); # prints "3", $x is still 2 
     print_var_plus_one($x);  # prints "3", $x is now 3 ! 
     print $x;      # prints "3" 

    This is spooky action-at-a-distance and is very hard to debug if it's 
    not intentional and well-documented (like `chop' or `chomp'). 

    An exception is made for the usual delegation idiom 
    `$object->SUPER::something(@_)'. Only `SUPER::' and `NEXT::' are 
    recognized (though this is configurable) and the argument list for the 
    delegate must consist only of `(@_)'. 

Answer 4

In einigen Fällen kann Perl :: Critic PBP-Richtlinien nicht genau erzwingen, so dass es eine Annäherung erzwingen kann, die versucht, den Geist der Conway-Richtlinien zu entsprechen. Und es ist durchaus möglich, dass wir PBP falsch interpretiert oder falsch angewendet haben. Wenn Sie etwas finden, das nicht richtig riecht, senden Sie bitte einen Fehlerbericht an bug-perl-critic@rt.cpan.org und wir werden uns sofort darum kümmern.

Danke,

-Jeff

Answer 5

Ich denke, Sie in der Regel Verschiebung vermeiden sollte, wenn es nicht wirklich notwendig ist!

lief einfach in einen Code wie folgt aus:

sub way { 
    my $file = shift; 
    if (!$file) { 
    $file = 'newfile'; 
    } 
    my $target = shift; 
    my $options = shift; 
} 

Wenn Sie etwas in diesem Code beginnen zu ändern, gibt es eine gute Chance, dass Sie accidantially die Reihenfolge der Verschiebungen ändern könnte oder vielleicht ein überspringen und alles geht Southway . Außerdem ist es schwer zu lesen - weil Sie nicht sicher sein können, dass Sie wirklich alle Parameter für das Sub sehen, weil einige Zeilen darunter möglicherweise eine andere Verschiebung sind ... Und wenn Sie einige Regexes dazwischen verwenden, können sie den Inhalt von $ _ und ersetzen Seltsames Zeug beginnt zu passieren ...

Ein direkter Vorteil der Verwendung des Entpackens my (...) = @_ ist, dass Sie einfach den (...) Teil kopieren und einfügen können, wo Sie die Methode aufrufen und haben eine nette Unterschrift :) Sie können sogar die gleichen Variablennamen verwenden und müssen nichts ändern!

Ich denke shift impliziert Listenoperationen, bei denen die Länge der Liste dynamisch ist und Sie ihre Elemente einzeln behandeln wollen oder wo Sie explizit eine Liste ohne das erste Element benötigen. Aber wenn Sie nur die ganze Liste den X-Parametern zuweisen möchten, sollte Ihr Code das mit meinen (...) = @_; niemand muss sich wundern.