Sollte ich vermeiden Sie verschachtelte if-Anweisungen in Perl?

Mache ich einige Perl-und da mein verschachtelte "wenn" - Aussagen ist das fahren mich verrückt. Ich habe es geschafft zu reduzieren, einige von Ihnen mit guard blockiert, die in einem anderen Abschnitt, aber ich bin hier hängengeblieben.

Glaubst du, ich kann den code belassen wie er ist, oder ist es eine "richtige" Art und Weise umgestalten, die folgenden ? (Auch ich zugeben, als relativ neu in Perl)

Dies ist eigentlich ein Unterprogramm Fragen für den Benutzer Eingang für jeden Parameter eine Liste (externe Datei). $[3] wird das matching-pattern, $[2] ist der default-Wert für die betrachteten parameter (NULL, wenn es keines gibt), $_[1] gibt an, ob es obligatorisch ist oder nicht. der 'next' - Anweisung bezieht sich auf den nächsten parameter Lesen (while-Schleife).

Mit jeder s Hilfe (vielen Dank !), hier ist die neueste version.

100         if ( $input ne '' && ( $input !~ $match || $input =~ /'.+'/ ) ) {
101             print "! Format not respected. Match : /$match/(without \' \')\n";
102             next;
103         }
104         if ( $input eq '' ) {
105             if ( $default eq 'NULL' ) {
106                 if ( $manda eq 'y' ) {
107                     print "! Mandatory parameter not filled in\n";
108                     next;
109                 }
110                 print "+ Ignoring parameter.\n";
111                 $input = '';
112             }
113             else {
114                 print "+ Using default value\n";
115                 $input = $default;
116             }
117         }
 98        if($input eq ''){
 99             if($_[2] eq 'NULL'){
100                 if($_[1] eq 'y'){
101                     print "! Mandatory parameter not filled in\n";
102                     next;
103                 }
104                 else{
105                     print "+ Ignoring parameter.\n";
106                     $input = '';
107                 }
108             }
109             else{
110                 print "+ Using default value\n";
111                 $input = $_[2];
112             }
113         }
114         elsif($input !~ $_[3] || $input =~ /'.+'/){
115                 print "! Format not respected. Match : /$_[3]/(without \' \')\n"; 
116                 next;
117             }
118         }
  • Was konkret ist es, das treibt Sie verrückt über diese verschachtelten ifs?
  • Ich weiß nicht, ich habe einfach das Gefühl es ist eine andere Art des Schreibens, die...
InformationsquelleAutor Isaac Clarke | 2009-07-28
  1. 10

    Hier ist eine etwas besser lesbare version des chaos' Antwort:

    # Set sane variable names...
my ($is_required, $default, $pattern) = @_

# Convert the external string convention for simpler evaluation...
$default = undef if $default eq 'NULL'

# Refuse problematic input before going any further...
if ($input ne '' && $input !~ $pattern || $input =~ /'.+'/) {
    print "! Format not respected. Match : /$pattern/(without \' \')\n"; 
    next;
}


# If there was no input string...
if($input eq '') {

    # Set the default, if one was provided...
    if( $default ) {
        print "+ Using default value\n";
        $input = $default;
    } 
    # otherwise, complain if a default was required...
    else {
        if( $is_required eq 'y' ){
            print "! Mandatory parameter not filled in\n";
            next;
        }
        print "+ Ignoring parameter (no input or default provided).\n";
    }
}

    Die wichtigsten Punkte sind:

    • Sie brauchen nicht sonst wenn Sie verlassen der aktuellen Schleife mit nächsten
    • Außergewöhnlichen Fällen umgegangen werden soll, die erste
    • Können Sie erheblich verbessern Sie die Lesbarkeit durch die Verwendung von benannten Variablen
    • Dank für, die. Unsere Antworten gekreuzt (siehe meinen ersten Beitrag Bearbeiten). Btw, in meinem code $is_required Kräfte Benutzer zu füllen, es ist keine Beschwerde :p (ändert nichts, obwohl Sie noch nicht Lesen Sie die gesamte subroutine)
    • Sorry für Doppel-post, aber ich mag deine Art zu kommentieren; und durch ", die Sie nicht gelesen haben," meinte ich, "das habe ich nicht geschrieben".
    • Danke, obwohl ich keinen Anspruch auf eine Gutschrift. Kommentar-Stil ist Damian Conway ' s - nahm ich es nach dem Lesen seine Sachen, denn ich mochte es auch. 😉
    InformationsquelleAutor ire_and_curses
  2. 4

    Einen alternativen Ansatz, der hilft manchmal mit der Lesbarkeit ist, um einige oder alle der Filialen in der gut-namens code verweist. Hier ist einer auf die Idee zu starten:

    $format_not_respected = sub {
    return 0 if ...;
    print "! Format not respected....";
    return 1;
}
$missing_mandatory_param = sub {
    return 0 if ...;
    print "! Mandatory parameter not filled in\n";
    return 1;
}

next if $format_not_respected->();
next if $missing_mandatory_param->();
etc...
    • Ich wusste nicht, über das, danke ! Auch wenn in meinem Fall, ich bin bereits in einem Unterprogramm (verschachtelte wenn-oder sub-sub-routine, das ist hier die Frage), dass könnte sich als nützlich für andere Skripte.
    • Das wird zum kompilieren von ein paar subs jedes mal, wenn Sie diese Funktion aufrufen-ist, dass wirklich was möchten Sie tun? Es ist eine nette Idee--und ich gab Sie ein, aber wenn dieses genannt wird, eine Menge, es ist besser, nicht zu verwenden capture Verhalten. (Ich denke.)
    InformationsquelleAutor FMc
  3. 3

    Den Hauptanliegen ist, halten Sie den code lesbar.

    Wenn man lesbaren code mit verschachtelten if-Anweisungen, gehen Sie vor. Aber halten Sie den gesunden Menschenverstand zu jeder Zeit aktiv.

    • Sollten Sie aufrecht zu erhalten, mein code, würde Sie Schwierigkeiten haben, das zu tun ?
    • Nein. (Aber ich bin trainiert, um zu pflegen, schwer zu Lesen code, also bin ich keine gute Referenz).
    InformationsquelleAutor Toon Krijthe
  4. 3
    if($input ne '' && ($input !~ $_[3] || $input =~ /'.+'/)) {
    print "! Format not respected. Match : /$_[3]/(without \' \')\n"; 
    next;
}
if($input eq '') {
    if($_[2] eq 'NULL') {
        if($_[1] eq 'y'){
            print "! Mandatory parameter not filled in\n";
            next;
        }
        print "+ Ignoring parameter.\n";
        $input = '';
    } else {
        print "+ Using default value\n";
        $input = $_[2];
    }
}
    • Ich mag das ! Danke ! (außer die Streicheleinheiten anderes :p)
    InformationsquelleAutor chaos
  5. 2

    Gängige Praxis ist die Definition von Konstanten für deine array Indizes, und geben Sie Ihnen aussagekräftige Namen. Wie:

    use constant MANDATORY => 1,
             DEFAULT => 2,
             PATTERN => 3;
...
if($_[DEFAULT] eq 'NULL') {
   ...
}

    Soweit verschachteln-Sie sollten versuchen oft zur Reduzierung der Gedankenstrich (d.h. halten die Ebene der Schachtelung zu tief), aber nie auf Kosten zu halten, den code verständlich. Ich habe kein problem mit dem Niveau der Verschachtelung, aber das ist auch nur ein kleiner Ausschnitt des Codes. Wenn es wirklich ein Problem, Sie könnte brechen, die die Bedingungen in separaten Unterprogrammen.

    • Wie gesagt, es ist ein Unterprogramm, alle meine Variablen sind lokal. Ich kann daher nicht die Verwendung der "use" - Anweisung ? Schachtelung ist nicht ein Problem auf dem rest des Codes, zum Glück. Danke für deine Antwort.
    • 'Konstanten' hat einige Nachteile. Konstanten erstellt mit Konstanten nicht interpoliert werden (z.B. strings), da Sie keine Siegel, und nicht lexikalisch Gültigkeitsbereich zur Laufzeit. Sie sind Paket-Bereich und erzeugt bei der Kompilierung. Dies ist ein problem, wenn man eine Konstante zur Laufzeit, z.B. durch eine Funktion. Dies ist beschrieben, viel besser, und mit exzellenten Beispielen in dem Buch "Perl Best Practices" von Damian Conway.
    InformationsquelleAutor Andrew Barnett
  6. 1

    Wenn Sie die Logik, die erforderlich geschachtelte if-Anweisung, dann denke ich, es ist nichts falsch mit Ihnen.

    Jedoch, Sie könnte verbessern Sie Ihre code-Lesbarkeit durch

    1. Mit nur ein wenig mehr weißen Raum und
    2. Mit Ihrem eigenen Variablen anstelle von direkten Betrieb auf @_

    Ist das nicht ein bisschen mehr lesbar?

     98        if ($input eq '') {
 99             if ($default eq 'NULL'){
100                 if ($input eq 'y'){
101                     print "! Mandatory parameter not filled in\n";
102                     next;
103                 }
104                 else {
105                     print "+ Ignoring parameter.\n";
106                     $input = '';
107                 }
108             }
109             else {
110                 print "+ Using default value\n";
111                 $input = $default;
112             }
113         }
114         elsif ($input !~ $foo || $input =~ /'.+'/) {
115                 print "! Format not respected. Match : /$foo/(without \' \')\n"; 
116                 next;
117             }
118         }
    • Zu Punkt 1. ich bin mit Perltidy jeder einmal in eine Weile. Ich bin versucht derzeit Probleme zu lösen und debug vorher. 2. Ich habe gelesen (in O 'Reilly' s Buch und anderswo), dass es $_ und $@ ausgiebig wurden, ohne mentionning jeder Nachteil ?
    • 1. Versuchen, Probleme zu lösen, ist viel einfacher, mit leicht zu lesenden code. 2. Der Nachteil ist die Lesbarkeit. Beim ersetzen Sie Ihre verschiedenen Verwendungen von $_[x], z.B., habe ich sofort bemerkt, dass Ihre Beschreibung von dem, was diese Variablen halten kann nicht ganz korrekt.
    • 1. Du hast absolut Recht. Ich mag den code, wie es ist, aber es wird sicherlich beibehalten werden, die von anderen (zunächst Sie). 2. @_ ist ein array holding die Liste der übergebenen Parameter (by value) an die Funktion. Richtig ? Für $_, ich bin nur verwenden, wenn r/w (in) ein filehandle.
    • Da hast du Recht @_. Aber es ist am besten Praxis, um die Werte in @_ in Skalare Variablen mit anständigen Namen.
    • Ja, sir. Tun wird. Danke !
    InformationsquelleAutor innaM
  7. 0

    Gegeben, dass Sie wird wahrscheinlich nicht ein spaghetti - goto sonst Absolut Keine.

    Was besser sein könnte, ist ein switch case.

    • Ich habe meine Lektion gelernt : gehe zu ist die HÖLLE. 😉 Nie darüber nachgedacht. Switch case nicht wirklich hier, da ich Teste 4 verschiedene Variablen.
    • Nicht du meinst given/when?
    • Ist es nicht erst mit 'feature' oder 'wechseln 'perl 6.0" ?
    InformationsquelleAutor nik
  8. 0

    könnte man vereinfachen Sie den folgenden, wenn Sie nicht wie alle anderen.

    if($input eq ''){
    $input = $_[2];
    $output = "+ Using default value\n";
    if($_[2] eq 'NULL'){
        $input = '';
        $output = "+ Ignoring parameter.\n";
        if($_[1] eq 'y'){
            $output = "! Mandatory parameter not filled in\n";
        }
    }
}
elsif($input !~ $_[3] || $input =~ /'.+'/){
    $output = "! Format not respected. Match : /$_[3]/(without \' \')\n"; 
}
print $output;
    • imho, es verlor etwas die Lesbarkeit. Trotzdem danke 😉
    InformationsquelleAutor Mark Synowiec
  9. 0

    Ich denke, der wichtigste (wenn nicht einzige) Grund für die Bedenken regardong nesting-Algorithmus ist die Komplexität. Auf der anderen Fällen sollten Sie sich sorgen machen über Lesbarkeit und Wartbarkeit, die sich also mit propoer kommentieren und Einrücken.

    Finde ich immer eine gute übung in maintanability Lesen Alter code von mir, nicht nur, um feedback über die Lesbarkeit, sondern auch auf Technik...

    InformationsquelleAutor Donato Azevedo
  10. -2

    Ich nehme an, Sie könnten tun, Logik-Kombinationen zu glätten Sie es heraus:

    if(($input eq '')&&($_[2] eq 'NULL')&&($_[1] eq 'y')){
  print "! Mandatory parameter not filled in\n";
  next;
}

elsif(($input eq '')&&($_[2] eq 'NULL')){
  print "+ Ignoring parameter.\n";
  $input = '';
}

elsif($input eq ''){
  print "+ Using default value\n";
  $input = $_[2];
  next;
}


elsif($input !~ $_[3] || $input =~ /'.+'/){
  print "! Format not respected. Match : /$_[3]/(without \' \')\n";
}

print $output;

    Dann könnten Sie einen Schalter, um es ein wenig besser.

    • Dies eigentlich war meine vorige version, die '&&' tests gefiel mir nicht, obwohl.
    • Dies vermindert die Lesbarkeit und Geschwindigkeit.
    • Das ist nicht einmal Perl. Perl nicht elseif nur elsif.
    • die Lesbarkeit ist wichtiger als die kleinere Geschwindigkeit der Unterschied in dieser situation, und nach der Frage, Autor, flacher war mehr lesbar für ihn, und das ist es, was er wollte. @Brad Gilbert Okay, Sie haben mich erwischt, ich weiß gar nicht pearl, aber es spielt keine Rolle, es ist offensichtlich, was elseif ist, ist es nicht. Ich habe die Antwort für Sie.
    InformationsquelleAutor Shawn J. Goff
Schreibe einen Kommentar