Czy należy unikać zagnieżdżonych instrukcji if w Perlu?

Question

Robię trochę Perla i widząc moje zagnieżdżone stwierdzenia "jeśli" doprowadza mnie do szału. Udało mi się zmniejszyć niektóre z nich z blokami strażniczymi w innej sekcji, ale utknąłem tutaj.

Czy sądzisz, że mogę pozostawić kod w niezmienionym stanie, lub czy istnieje "właściwy" sposób na refaktoryzację? (Przyznaję również, że jest to relatywnie nowy produkt w Perlu).

To jest właściwie podprogram z pytaniem o dane wejściowe użytkownika dla każdego parametru listy (plik zewnętrzny). $ [3] jest pasującym wzorcem, $ [2] jest domyślną wartością dla rozważanego parametru (NULL, jeśli nie ma), $ _ [1] określa, czy jest obowiązkowe czy nie. "następna" instrukcja odnosi się do następnego odczytanego parametru (while loop).

Z pomocą wszystkich (dzięki!), Oto najnowsza wersja.

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   } 

Answer 1

Oto nieco bardziej czytelną wersję chaosu odpowiedź:

# 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"; 
    } 
} 

kluczowych punktów są:

• Nie trzeba inny jeśli wyjściu z pętli prądowej z następny
• Nadzwyczajne sprawy powinny być traktowane jako pierwsze
• Możesz znacznie poprawiają czytelność przy użyciu nazwanych zmiennych

Answer 2

Jeśli logika wymagane zagnieżdżone if to chyba nie ma nic złego z nimi.

Jednakże, można poprawić czytelność kodzie poprzez

1. Korzystanie tylko trochę więcej spacji i
2. Przy użyciu własnych zmiennych zamiast działających bezpośrednio na @_

ISN” Czy to jest nieco bardziej czytelne?

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   } 

Answer 3

Powszechną praktyką jest definiowanie stałych dla indeksów tablic i nadawanie im znaczących nazw. Takich jak:

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

miarę gniazdowania - Powinieneś często starają się zmniejszyć wcięcie (co oznacza utrzymanie poziomu zagnieżdżenia niskie), ale nigdy nie robić kosztem utrzymania kod zrozumiały. Nie mam problemu z poziomem zagnieżdżenia, ale jest to również po prostu niewielkie wycięcie twojego kodu. Jeśli to naprawdę problem, możesz podzielić warunki na osobne podprogramy.

Answer 4

Biorąc pod uwagę, że prawdopodobnie będzie zrobić spaghetti goto inaczej, absolutnie nr

Co może być lepiej jest switch case.

Answer 5

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]; 
    } 
} 

Answer 6

możesz uprościć poniższe, jeśli nie lubisz wszystkich innych.

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; 

Answer 7

Głównym problemem jest zapewnienie czytelności kodu.

Jeśli możesz uzyskać czytelny kod z zagnieżdżonymi instrukcjami if, śmiało. Ale utrzymuj zdrowy rozsądek przez cały czas.

Answer 8

Przypuszczam, że można zrobić kombinacje logiczne do spłaszczyć go:

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; 

Następnie można użyć przełącznika, aby zrobić to trochę lepiej.

Answer 9

Myślę, że głównym (jeśli nie tylko) powodem do obaw dotyczących zagnieżdżania jest złożoność algorytmu. W innych przypadkach powinieneś się martwić o czytelność i łatwość obsługi, do której można się odwołać za pomocą komentowania i wcięcia.

zawsze znaleźć dobre ćwiczenie w maintanability czytać stary kod z kopalni, a nie tylko do informacji zwrotnych na temat czytelności ale również na technice ...

Answer 10

Alternatywnym podejściem, że czasami pomaga czytelności jest umieszczenie niektórych lub wszystkich oddziałów w dobrze nazwanych odnośnikach do kodu. Oto początek pomysłu:

$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...