Dlaczego instrukcje „if elif else” praktycznie nigdy nie mają formatu tabeli?

if   i>0 : return sqrt(i)  
elif i==0: return 0  
else     : return 1j * sqrt(-i)

VS

if i>0:  
   return sqrt(i)  
elif i==0:  
   return 0  
else:  
   return 1j * sqrt(-i)  

Biorąc pod uwagę powyższe przykłady, nie rozumiem, dlaczego właściwie nigdy nie widzę pierwszego stylu w bazach kodu. Dla mnie zmieniasz kod w format tabelaryczny, który wyraźnie pokazuje, czego chcesz. Pierwsza kolumna może być praktycznie zignorowana. Druga kolumna określa warunek, a trzecia kolumna zawiera oczekiwane dane wyjściowe. Wydaje mi się, przynajmniej prosty, łatwy do odczytania. Jednak zawsze widzę, że ten prosty rodzaj sprawy / przełącznika pojawia się w rozszerzonym, wciętym formacie. Dlaczego? Czy ludzie uważają, że drugi format jest bardziej czytelny?

Jedynym przypadkiem, gdy może to być problematyczne, jest zmiana kodu i wydłużenie go. W takim przypadku myślę, że całkowicie rozsądne jest przeformułowanie kodu na długi, wcięty format. Czy wszyscy robią to w drugą stronę, po prostu dlatego, że zawsze tak było? Będąc adwokatem diabła, sądzę, że innym powodem może być to, że ludzie znajdują dwa różne formaty w zależności od złożoności instrukcji if / else, które są mylące? Doceniony zostanie każdy wgląd.

Jednym z powodów może być to, że nie używasz języków, w których jest popularny.

Kilka kontrprzykładów:

Haskell ze strażnikami i wzorami:

sign x |  x >  0        =   1
       |  x == 0        =   0
       |  x <  0        =  -1

take  0     _           =  []
take  _     []          =  []
take  n     (x:xs)      =  x : take (n-1) xs

Erlang z wzorami:

insert(X,Set) ->
    case lists:member(X,Set) of
        true  -> Set;
        false -> [X|Set]
    end.

Emacs lisp:

(pcase (get-return-code x)
  (`success       (message "Done!"))
  (`would-block   (message "Sorry, can't do it now"))
  (`read-only     (message "The shmliblick is read-only"))
  (`access-denied (message "You do not have the needed rights"))
  (code           (message "Unknown return code %S" code)))

Generalnie widzę, że format tabeli jest dość popularny w językach funkcjonalnych (i ogólnie w oparciu o wyrażenia), podczas gdy łamanie linii jest najbardziej popularne w innych (głównie na podstawie instrukcji).

Jest bardziej czytelny. Kilka powodów, dla których:

• Prawie każdy język używa tej składni (nie wszystkie, w większości - twój przykład wygląda jednak na Python)
• isanae zwrócił uwagę w komentarzu, że większość debuggerów jest oparta na liniach (a nie na instrukcjach)
• Zaczyna wyglądać jeszcze bardziej brzydko, jeśli trzeba wstawić średniki lub nawiasy klamrowe
• Płynie od góry do dołu
• Wygląda okropnie nieczytelnie, jeśli masz coś innego niż trywialne zwroty
  • Każda znacząca składnia wcięcia jest tracona podczas przeglądania kodu, ponieważ kod warunkowy nie jest już wizualnie oddzielony (od Dana Neely )
  • Będzie to szczególnie złe, jeśli będziesz kontynuować łatanie / dodawanie elementów do instrukcji 1-line if
• Jest to czytelne tylko wtedy, gdy wszystkie twoje czeki są mniej więcej tej samej długości
• Oznacza to, że nie można sformatować skomplikowanych instrukcji, jeśli instrukcje w instrukcjach wielowierszowych, będą musiały być onelinerami
• O wiele bardziej prawdopodobne jest zauważenie błędów / logiki podczas czytania w pionie linia po linii, nie próbując parsować wielu linii razem
• Nasz mózg odczytuje węższy, wyższy tekst DUŻO szybciej niż długi, poziomy tekst

Z chwilą, gdy spróbujesz to zrobić, ostatecznie przerobisz go na instrukcje wielowierszowe. Co oznacza, że ​​zmarnowałeś czas!

Również ludzie nieuchronnie dodają coś takiego:

if i>0:  
   print('foobar')
   return sqrt(i)  
elif i==0:  
   return 0  
else:  
   return 1j * sqrt(-i)  

Nie trzeba tego często robić, zanim zdecydujesz, że ten format jest znacznie lepszy niż alternatywa. Ach, ale można to wszystko wstawić w jednym wierszu! Enderland umiera w środku .

Albo to:

if   i>0 : return sqrt(i)  
elif i==0 and bar==0: return 0  
else     : return 1j * sqrt(-i)

Co jest naprawdę bardzo denerwujące. Nikt nie lubi formatować takich rzeczy.

I na koniec, rozpoczniesz świętą wojnę problemu „ile spacji dla zakładek”. To, co renderuje się doskonale na ekranie jako format tabeli, może nie renderować się na moim w zależności od ustawień.

Czytelność i tak nie powinna zależeć od ustawień IDE.

Jestem głęboko przekonany, że „kod jest czytany wiele razy, napisany kilka - więc czytelność jest bardzo ważna”.

Kluczową rzeczą, która pomaga mi, gdy czytam kod innych ludzi, jest przestrzeganie „normalnych” wzorców, które moje oczy są wyszkolone do rozpoznawania. Najłatwiej mogę odczytać wciętą formę, ponieważ widziałem ją tyle razy, że rejestruje się prawie automatycznie (przy niewielkim wysiłku poznawczym z mojej strony). Nie dlatego, że jest „ładniejszy” - to dlatego, że przestrzega konwencji, do których jestem przyzwyczajony. Konwencja bije „lepiej” ...

Wraz z innymi już wspomnianymi wadami układ tabelaryczny zwiększa szanse na konflikty scalania kontroli wersji wymagające ręcznej interwencji.

Gdy blok wyrównywanego tabelarycznie kodu musi zostać wyrównany, system kontroli wersji potraktuje każdy z tych wierszy jako zmodyfikowany:

diff --git a/foo.rb b/foo.rb
index 40f7833..694d8fe 100644
--- a/foo.rb
+++ b/foo.rb
@@ -1,8 +1,8 @@
 class Foo

   def initialize(options)
-    @cached_metadata = options[:metadata]
-    @logger          = options[:logger]
+    @metadata = options[:metadata]
+    @logger   = options[:logger]
   end

 end

Załóżmy teraz, że w międzyczasie w innej gałęzi programista dodał nową linię do bloku wyrównanego kodu:

diff --git a/foo.rb b/foo.rb
index 40f7833..86648cb 100644
--- a/foo.rb
+++ b/foo.rb
@@ -3,6 +3,7 @@ class Foo
   def initialize(options)
     @cached_metadata = options[:metadata]
     @logger          = options[:logger]
+    @kittens         = options[:kittens]
   end

 end

Scalenie tego oddziału nie powiedzie się:

wayne@mercury:/tmp/foo$ git merge add_kittens
Auto-merging foo.rb
CONFLICT (content): Merge conflict in foo.rb
Automatic merge failed; fix conflicts and then commit the result.

Gdyby modyfikowany kod nie używał wyrównania tabelarycznego, scalanie przebiegałoby automatycznie.

(Ta odpowiedź była „plagiatem” z mojego własnego artykułu zniechęcającego do wyrównania tabelarycznego w kodzie).

Formaty tabelaryczne mogą być bardzo ładne, jeśli rzeczy zawsze mieszczą się w przydzielonej szerokości. Jeśli jednak coś przekracza przydzieloną szerokość, często konieczne jest posiadanie części stołu, która nie jest wyrównana z resztą, lub dostosowanie układu wszystkiego innego w tabeli, aby pasował do długiego elementu .

Jeśli pliki źródłowe były edytowane przy użyciu programów zaprojektowanych do pracy z danymi w formacie tabelarycznym i mogących obsługiwać zbyt długie elementy przy użyciu mniejszego rozmiaru czcionki, dzieląc je na dwie linie w tej samej komórce itp., Wówczas warto zastosować tabelaryczne formatuje częściej, ale większość kompilatorów chce plików źródłowych wolnych od znaczników, które edytorzy musieliby przechowywać, aby zachować formatowanie. Używanie linii ze zmiennymi wcięciami, ale żaden inny układ nie jest tak przyjemny jak formatowanie tabelaryczne w najlepszym przypadku, ale nie powoduje prawie tyle problemów w najgorszym przypadku.

Istnieje instrukcja „switch”, która zapewnia tego rodzaju rzeczy w szczególnych przypadkach, ale myślę, że nie o to pytasz.

Widziałem, czy instrukcje w formacie tabeli, ale musi istnieć duża liczba warunków, aby było warto. 3 jeśli instrukcje najlepiej wyświetlać w tradycyjnym formacie, ale jeśli masz 20, to znacznie łatwiej jest wyświetlić je w dużym bloku, który jest sformatowany, aby był wyraźniejszy.

I jest sens: jasność. Jeśli ułatwia to dostrzeżenie (a twój pierwszy przykład nie jest łatwy do ustalenia, gdzie znajduje się: separator), sformatuj go odpowiednio do sytuacji. W przeciwnym razie trzymaj się tego, czego oczekują ludzie, ponieważ zawsze łatwiej to rozpoznać.

Jeśli Twoje wyrażenie jest naprawdę łatwe, większość języków programowania oferuje operator:: rozgałęziający:

return  ( i > 0  ) ? sqrt( i)
      : ( i == 0 ) ? 0
        /* else */ : 1j * sqrt( -i )

Jest to krótki czytelny format tabelaryczny. Ale ważną częścią jest: na pierwszy rzut oka widzę, czym jest „ważna” akcja. To jest oświadczenie zwrotne! O wartości decydują pewne warunki.

Jeśli z drugiej strony masz gałęzie, które wykonują inny kod, uważam, że wcięcie tych bloków jest o wiele bardziej czytelne. Ponieważ teraz istnieją różne „główne” działania w zależności od instrukcji if. W jednym przypadku rzucamy, w jednym logujemy się i zwracamy lub po prostu wracamy. Istnieje inny przepływ programu w zależności od logiki, więc bloki kodu zamykają różne gałęzie i sprawiają, że są one bardziej widoczne dla programisty (np. Szybkie odczytywanie funkcji w celu uchwycenia przepływu programu)

if ( i > 0 )
{
    throw new InvalidInputException(...);
}
else if ( i == 0 )
{
    return 0;
}
else
{
    log( "Calculating sqrt" );
    return sqrt( -i );
}

Jak już powiedział Enderland, zakładasz, że masz tylko jeden „powrót” jako akcję i że możesz oznaczyć ten „powrót” na końcu warunku. Chciałbym podać dodatkowe szczegóły na temat tego, dlaczego to się nie powiedzie.

Nie wiem, jakie są twoje preferowane języki, ale pisałem w C od dłuższego czasu. Istnieje wiele standardów kodowania, których celem jest uniknięcie pewnych standardowych błędów kodowania poprzez niedopuszczenie konstrukcji kodu podatnych na błędy, zarówno podczas wstępnego kodowania, jak i podczas późniejszej konserwacji. Najbardziej znam MISRA-C, ale są też inne i ogólnie wszystkie mają podobne reguły, ponieważ rozwiązują te same problemy w tym samym języku.

Jednym z popularnych błędów, którym często zajmują się standardy kodowania, jest ten mały problem: -

if (x == 10)
    do_something();
    do_something_else();

To nie robi tego, co myślisz. Jeśli chodzi o C, jeśli x wynosi 10, wtedy wywołujesz do_something(), ale następnie do_something_else()zostaje wywołany niezależnie od wartości x . Tylko akcja bezpośrednio po instrukcji „if” jest warunkowa. Może to być zamierzenie kodera, w którym to przypadku istnieje potencjalna pułapka dla opiekunów; lub może nie być to zgodne z zamierzeniami kodera, w którym to przypadku wystąpił błąd. To popularne pytanie podczas wywiadu.

Rozwiązaniem w standardach kodowania jest nałożenie nawiasów klamrowych wokół wszystkich działań warunkowych, nawet jeśli są one jednowierszowe. Teraz dostaniemy

if (x == 10)
{
    do_something();
    do_something_else();
}

lub

if (x == 10)
{
    do_something();
}
do_something_else();

a teraz działa poprawnie i jest jasne dla opiekunów.

Zauważysz, że jest to całkowicie niezgodne z twoim formatem tabeli.

Niektóre inne języki (np. Python) przyjrzały się temu problemowi i zdecydowały, że ponieważ koderzy używają białych znaków do wyjaśnienia układu, dobrym pomysłem byłoby użycie białych znaków zamiast nawiasów klamrowych. W Pythonie

if x == 10:
    do_something()
    do_something_else()

uzależnia wywołania do obu do_something()i do_something_else()od x == 10, podczas gdy

if x == 10:
    do_something()
do_something_else()

oznacza, że ​​tylko do_something()zależy od x i do_something_else()zawsze jest wywoływane.

Jest to ważna koncepcja i znajdziesz ją w kilku językach. (Po raz pierwszy zobaczyłem to w Occam2, dawno temu.) Ponownie jednak możesz łatwo zauważyć, że twój format tabeli jest niezgodny z językiem.

Układ tabelaryczny może być użyteczny w kilku ograniczonych przypadkach, ale jest kilka razy, gdy jest to użyteczne w przypadku if.

W prostych przypadkach?: Może być lepszym wyborem. W średnich przypadkach zmiana jest często lepsza (jeśli Twój język ma taką opcję). W skomplikowanych przypadkach może się okazać, że lepiej sprawdzą się tabele połączeń.

Wiele razy przy refaktoryzacji kodu przestawiałem go na tabelaryczny, aby uczynić go oczywistym. Rzadko zdarza się, że zostawiam to w ten sposób, ponieważ w większości przypadków istnieje lepszy sposób na rozwiązanie problemu po jego zrozumieniu. Czasami zabrania się tego praktyka kodowania lub standard układu, w którym to przypadku przydatny jest komentarz.

Było kilka pytań na temat ?:. Tak, jest to operator trójskładnikowy (lub, jak lubię o tym myśleć, wartość if). przy pierwszym rumieniec ten przykład jest trochę skomplikowany?: (i nadużywanie?: nie poprawia czytelności, ale boli), ale z pewną myślą Przykład można zmienić w następujący sposób, ale myślę, że w tym przypadku przełącznik jest najbardziej czytelny rozwiązanie.

if i==0: return 0
return i>0?sqrt(i):(1j*sqrt(-i))

Nie widzę nic złego w formacie tabeli. Osobiste preferencje, ale użyłbym trójki w następujący sposób:

return i>0  ? sqrt(i)       :
       i==0 ? 0             :
              1j * sqrt(-i)

Nie trzeba powtarzać za returnkażdym razem :)