Stylizacja złożonego AND / OR instrukcji if

Jak stylizujesz złożone złożone ORAZ / LUB jeśli instrukcje dla maksymalnej czytelności? Jak wcinasz i gdzie umieszczasz łamanie linii? Moja szczególna sytuacja wygląda następująco. To zdecydowanie lepsze niż rozbijanie wszystkiego w jednym wierszu, ale nadal wygląda na bałagan.

if (
    (
        x == y
        && a != b
        && p.isGood() 
        && (
            i + u == b
            || q >= a
        )
    )
    || k.isSomething()
    || m > n
) {
    doSomething();
}

Twórz zmienne boolowskie dla każdego małego kroku:

bool step1 = i + u == b || q >= a;
bool step2 = a != b && p.isGood() && group1;
bool step3 = group2 || k.isSomething() || m > n;
if (step3) { doSomething(); }

Jest to oczywiście podobne do odpowiedzi Lacrymology, z wyjątkiem różnych nazw dla każdego kroku.

Jeśli nazwa step1, step2i step3w taki sposób, że tworzą dobry koncepcyjne sens, powinno to być zdecydowanie najbardziej czytelne. p.isGood()i k.isSomething()czasami może zostać wywołany w sytuacjach, w których nie byłoby go w oryginalnym kodzie, więc nie byłaby to opcja, jeśli te funkcje są drogie lub jeśli uruchamiasz ten kod w bardzo ciasnej pętli.

Z drugiej strony nie musisz się martwić spadkiem wydajności, jaki może ponieść tworzenie nowych zmiennych; dobry kompilator zoptymalizuje je.

Przykład z wykrywaniem kolizji prostokąta (którego prawdopodobnie nie użyłbyś ze względu na wspomniane wcześniej pogorszenie wydajności):

if((a.x + a.width >= b.x || b.x + b.width >= a.x)
 && (a.y + a.height >= b.y || b.y + b.width >= a.y)
)
{ collision(); }

Może stać się:

bool horizMatch = a.x + a.width >= b.x || b.x + b.width >= a.x;
bool vertMatch = a.y + a.height >= b.y || b.y + b.width >= a.y;
if(horizMatch && vertMatch) { collision(); }

Ponadto, jeśli chcesz zostawić swój kod bez zmian, myślę, że byłoby to również w porządku. Myślę, że twój kod jest dość czytelny. Oczywiście nie wiem, czym dokładnie a b x y i u p k m nsą, ale jeśli chodzi o strukturę, wygląda mi to dobrze.

Zazwyczaj zmieniam swój kod na bardziej modułowy, jeśli moje warunki warunkowe komplikują się.

Na tym poziomie złożoności zrobiłbym coś więcej

bool doIt = x == y && a != b && p.isGood();
doIt &= ( i + u == b || q >= a);
doIt |= k.isSomething() || m > n;

if(doIt)
{
    doSomething();
}

jest brzydki, ale czytelny i jestem pewien, że kompilator będzie wiedział, jak go refaktoryzować.

Z drugiej strony, jeśli kiedykolwiek zobaczę siebie w sytuacji, gdy piszę takie oświadczenie IF, ponownie zastanawiam się nad rozwiązaniem, ponieważ JESTEM PEWNY, że istnieje sposób na uproszczenie go lub przynajmniej wyodrębnienie niektórych z tych warunków (np. Może x == y && a != b && p.isGood()naprawdę po prostu znaczy this->isPolygon()i mogę zrobić tę metodę;

Z czasem coraz mniej mam obsesję na punkcie wyrównania w pionie, ale moja ogólna postać z wyrażeniami wieloliniowymi to ...

if (   (   (expr1 == expr2)
        || (expr3 == expr4)
        || (expr5 == expr6)
       )
    && (   (expr7 == expr8)
        || (expr9 == expra)
       )
   )
{
  blah;
}

Kluczowe punkty...

• Zamknięte pareny wyrównują się pionowo z otwartymi parens, tak jak z aparatami ortodontycznymi.
• Podwyrażenia pasujące do jednej linii znajdują się w jednej linii i są wyrównane w pionie po lewej stronie. Tam, gdzie poprawia to czytelność, operatory infix w tych częściach jednowierszowych są również wyrównane w pionie.
• Zamykające szelki naturalnie tworzą prawie puste linie, pomagając wizualnie grupować rzeczy.

Czasami sformatuję +i / *lub niektórzy inni operatorzy też to lubią. Całkiem kilka złożonych wyrażeń przyjmuje postać sumy produktu lub iloczynu sumy (która może odnosić się do boolowskich „sum” i „produktów”), więc prawdopodobnie jest na tyle powszechna, że ​​warto stosować spójny styl.

Uważaj jednak na to. Często lepiej jest zrefaktoryzować (przenieść części wyrażenia do funkcji lub obliczyć i zapisać części pośrednie w zmiennej), zamiast używać wcięcia, aby uczynić nadmiernie złożone wyrażenie bardziej czytelnym.

Jeśli wolisz układać swoje ścisłe pareny po prawej stronie, nie nienawidzę tego, ale myślę, że nie jest tak źle. Mówiąc zbyt daleko, ryzykujesz, że błąd może sprawić, że wcięcie będzie mylnie interpretować to, co robią nawiasy.

if (   (   (expr1 == expr2)
        || (expr3 == expr4)
        || (expr5 == expr6))

    && (   (expr7 == expr8)
        || (expr9 == expra)))
{
  blah;
}

http://www.codinghorror.com/blog/2006/01/flattening-arrow-code.html

Zgadzam się z odpowiedzią JohnFx, a także odpowiedzią Lacrymology. Zbudowałbym zestaw funkcji (najlepiej statycznych), które osiągają małe cele, a następnie rozbudowałem je w inteligentny sposób.

A co powiesz na coś takiego? Uwaga: nie jest to idealne rozwiązanie, ale działa. Istnieją sposoby na dalsze oczyszczenie tego, ale potrzebne są bardziej szczegółowe informacje. Uwaga: ten kod powinien działać równie szybko, ponieważ kompilator jest inteligentny.

// Currently based on members or global vars
// (which is often a bad idea too)
function doSomethingCondirionally()
{
  if (k.isSomething() || m > n)
  {
    doSomething();
    return;
  }

  // Else ... 
  if (x != y) return;
  if (a == b) return;
  if (!p.isGood()) return;

  // Final, positive check
  if (i + u == b || q >= a)
  {
    doSomething();
  }
}

Z powodu tego, co jest warte, zdziwiłem się, widząc, że twój przykład przypomina skomplikowane predykaty, które napisałem. Zgadzam się z innymi, że skomplikowany predykat nie jest najlepszy ze względu na łatwość utrzymania lub czytelność, ale czasami pojawiają się.

Chciałbym podkreślić, że poprawiłeś tę część: && a != b NIGDY nie umieszczaj złącza logicznego na końcu linii, zbyt łatwo jest przeoczyć wizualnie. Innym miejscem, w którym NIGDY nie należy umieszczać operatora na końcu wiersza, jest konkatenacja łańcuchów, w językach z takim operatorem.

Zrób to:

String a = b
   + "something"
   + c
   ;

Nie rób tego:

String a = b +
   "something" +
   c;

Jeśli warunek jest tak skomplikowany, zwykle oznacza to, że należy go podzielić na części. Być może jedna klauzula może być przypisana do zmiennej pośredniej. Być może jedna klauzula może zostać przekształcona w metodę pomocniczą. Zasadniczo wolę nie mieć tak wielu znaków „i” w jednej linii.

Możesz podzielić kod na wiele instrukcji, co ułatwi zrozumienie. Ale prawdziwy ninja zrobiłby coś takiego. :-)

if
(
    (
        x == y
    &&
        a != b
    &&
        p.isGood()
    &&
        (
            i + u == b
        ||
            q >= a
        )
    )
||
    k.isSomething()
||
    m > n
)
{
    doSomething();
}