Flatten bedingt als Refactoring

Question

Bedenken Sie:

if (something) { 
    // Code... 
} 

Mit CodeRush installiert, es zu tun empfohlen:

if (!something) { 
    return; 
} 
// Code... 

Könnte jemand erklären, wie das besser? Sicherlich gibt es keinen Nutzen, was auch immer.

Answer 1

Isoliert, wie Sie es vorgestellt haben - kein Vorteil. Aber mark4o liegt direkt an: es ist weniger Verschachtelung, die sehr deutlich, wenn man sich selbst suchen, sagen sie eine 4-stufige Verschachtelung:

public void foo() { 
    if (a) 
     if (b) 
      if (c) 
       if (d) 
        doSomething(); 
} 

gegen

public void foo() { 
    if (!a) 
     return; 
    if (!b) 
     return; 
    if (!c) 
     return; 
    if (!d) 
     return; 
    doSomething(); 
} 

früh zurückkehrt wie diese Lesbarkeit verbessern.

Answer 2

Eine Stufe weniger Verschachtelung.

Answer 3

Ich glaube nicht, dass CodeRush es empfiehlt --- eher als Option.

Answer 4

In einigen Fällen ist es sauberer, alle Eingaben am Anfang einer Methode zu validieren und nur zu retten, wenn etwas nicht stimmt. Sie können eine Reihe von einstufigen if-Prüfungen haben, die nacheinander immer mehr spezifische Dinge prüfen, bis Sie sicher sind, dass Ihre Eingaben gut sind. Der Rest der Methode wird dann viel einfacher zu schreiben sein und wird tendenziell weniger geschachtelte Bedingungen haben.

Answer 5

IMO, es hängt davon ab, ob something oder !something der Ausnahmefall ist. Wenn es eine signifikante Menge an Code gibt, wenn something passiert, dann macht die Verwendung der !something-Bedingung mehr Sinn für Lesbarkeit und potentielle Verschachtelungsreduktion.

Answer 6

Es kann verwendet werden, um den Code lesbarer zu machen (durch weniger Verschachtelung). Ein gutes Beispiel finden Sie in here und here für eine gute Diskussion der Vorzüge.

void SomeMethod() 
{ 
    if (condition_1) 
    { 
     if (condition_2) 
     { 
      if (condition_3) 
      { 
       // code 
      } 
     } 
    } 
} 

Mit

:

void SomeMethod() 
{ 
    if (!condition_1) { return; } 
    if (!condition_2) { return; } 
    if (!condition_3) { return; } 

    // code 
} 

, die auf den Augen viel leichter ist,

Diese Art von Muster ist häufig zu ersetzen verwendet.

Answer 7

Nun, schauen Sie auf diese Weise an sie (ich php als Beispiel verwenden werden):

Sie ein Formular ausfüllen und zu dieser Seite: validate.php

Beispiel 1:

<?php 

if (valid_data($_POST['username'])) { 

    if (valid_data($_POST['password'])) { 

     login(); 

    } else { 
     die(); 
    } 

} else { 
    die(); 
} 

?> 

vs

<?php 

if (!valid_data($_POST['username'])) { 
    die(); 
} 

if (!valid_data($_POST['password'])) { 
    die(); 
} 

login(); 

?> 

Welche ist besser und einfacher zu warten? Denken Sie daran, dass dies nur zwei Dinge bestätigt. Stellen Sie sich das für eine Registerseite oder etwas anderes vor.

Answer 8

Dies ist ein herkömmliches Refactoring, das für Wartbarkeit gedacht ist.Siehe:

http://www.refactoring.com/catalog/replaceNestedConditionalWithGuardClauses.html

Mit einer Bedingung, es ist keine große Verbesserung. Aber es folgt dem "fail fast" -Prinzip, und Sie beginnen wirklich, den Vorteil zu bemerken, wenn Sie viele Bedingungen haben. Wenn Sie mit "strukturierter Programmierung" aufgewachsen sind, die normalerweise Funktionen mit einzelnen Ausstiegspunkten empfiehlt, mag das unnatürlich erscheinen, aber wenn Sie jemals versucht haben, Code zu debuggen, der drei oder mehr Ebenen geschachtelte Bedingungen hat, werden Sie anfangen zu schätzen es.

Answer 9

Ich erinnere mich sehr deutlich Markierungen auf einem Stück College Arbeit zu verlieren, weil ich mit dem

if (!something) { 
    return; 
} 
// Code... 

Format gegangen war. Mein Dozent gab an, dass es eine schlechte Übung sei, mehr als einen Ausgangspunkt in einer Funktion zu haben. Ich dachte, das war verrückt und über 20 Jahre Computerprogrammierung später, tue ich immer noch.

Um fair zu sein, lebte er in einer Ära, in der die Lingua Franca C war und Funktionen oft Seiten lang und voller verschachtelter Bedingungen waren, was es schwierig machte, zu verfolgen, was vor sich ging.

Damals wie heute ist Einfachheit die Königsdisziplin: Funktionen klein zu halten und sie gut kommentieren zu können, ist der beste Weg, Dinge lesbar und wartbar zu machen.