Warum haben "if elif else" -Anweisungen so gut wie nie das Format einer Tabelle?

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)  

Angesichts der obigen Beispiele verstehe ich nicht, warum ich den ersten Stil in Codebasen so gut wie nie sehe. Für mich wandeln Sie den Code in ein Tabellenformat um, das klar zeigt, was Sie wollen. Die erste Spalte kann praktisch ignoriert werden. Die zweite Spalte gibt den Zustand an und die dritte Spalte gibt Ihnen die gewünschte Ausgabe. Zumindest scheint es mir einfach und leicht zu lesen zu sein. Ich sehe diese einfache Art von Fall / Schalter-Situation jedoch immer im erweiterten Format mit eingerückten Tabulatoren. Warum ist das so? Finden die Leute das zweite Format besser lesbar?

Dies kann nur dann problematisch sein, wenn sich der Code ändert und länger wird. In diesem Fall halte ich es für absolut sinnvoll, den Code in das lange, eingerückte Format umzugestalten. Tun es alle auf die zweite Art und Weise, nur weil es immer so war? Als Anwalt eines Teufels kann ein weiterer Grund darin liegen, dass die Leute zwei unterschiedliche Formate finden, abhängig von der Komplexität der if / else-Anweisungen, die sie für verwirrend halten. Jede Einsicht wäre dankbar.

Ein Grund kann sein, dass Sie keine Sprachen verwenden, in denen es beliebt ist.

Einige Gegenbeispiele:

Haskell mit Wachen und mit Mustern:

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

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

Erlang mit Mustern:

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)))

Im Allgemeinen sehe ich, dass das Tabellenformat bei funktionalen Sprachen (und im Allgemeinen bei auf Ausdrücken basierenden) ziemlich beliebt ist, während das Brechen von Zeilen bei anderen am beliebtesten ist (meistens auf Anweisungen basierend).

Es ist besser lesbar. Ein paar Gründe warum:

• Fast jede Sprache verwendet diese Syntax (nicht alle, die meisten - Ihr Beispiel scheint jedoch Python zu sein).
• isanae wies in einem Kommentar darauf hin, dass die meisten Debugger zeilenbasiert sind (nicht anweisungsbasiert )
• Es sieht sogar noch hässlicher aus, wenn Sie Semikolons oder geschweifte Klammern einfügen müssen
• Es liest sich besser von oben nach unten
• Es sieht schrecklich unlesbar aus, wenn Sie etwas anderes als triviale Rückgabeanweisungen haben
  • Jede einrückende sinnvolle Syntax geht verloren, wenn Sie Code überfliegen, da der bedingte Code nicht mehr visuell getrennt ist (von Dan Neely ).
  • Dies ist besonders schlimm, wenn Sie weiterhin Elemente in die 1-zeilige if-Anweisung einfügen
• Es ist nur lesbar, wenn alle Ihre Schecks ungefähr gleich lang sind
• Dies bedeutet, dass Sie komplizierte Anweisungen nicht in mehrzeilige Anweisungen formatieren können. Sie müssen Oneliners sein
• Es ist weitaus wahrscheinlicher, dass ich Fehler / Logikflüsse bemerke, wenn ich vertikal zeilenweise lese und nicht versuche, mehrere Zeilen zusammen zu analysieren
• Unser Gehirn liest schmaleren, größeren Text VIEL schneller als langen, horizontalen Text

In dem Moment, in dem Sie dies versuchen, werden Sie es in mehrzeilige Anweisungen umschreiben. Was bedeutet, dass Sie nur Zeit verschwendet haben!

Man fügt auch unweigerlich Folgendes hinzu:

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

Es dauert nicht sehr oft, bis Sie feststellen, dass dieses Format viel besser ist als Ihre Alternative. Ah, aber Sie könnten alles in eine Zeile schreiben! Enderland stirbt an der Innenseite .

Oder dieses:

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

Was sehr, sehr ärgerlich ist. Niemand mag es, solche Dinge zu formatieren.

Und zuletzt werden Sie den heiligen Krieg des Problems "Wieviel Platz für Tabs?" Beginnen. Was auf Ihrem Bildschirm als Tabellenformat perfekt dargestellt wird, wird auf meinem möglicherweise nicht dargestellt, abhängig von den Einstellungen.

Die Lesbarkeit sollte sowieso nicht von den IDE-Einstellungen abhängen.

Ich bin fest davon überzeugt, dass "Code viele Male gelesen und nur wenige Male geschrieben wird - daher ist die Lesbarkeit sehr wichtig."

Eine wichtige Sache, die mir hilft, wenn ich den Code anderer Leute lese, ist, dass ich den „normalen“ Mustern folge, die meine Augen erkennen sollen. Ich kann das eingerückte Formular am einfachsten lesen, weil ich es so oft gesehen habe, dass es fast automatisch registriert wird (mit wenig kognitivem Aufwand von meiner Seite). Es ist nicht, weil es "hübscher" ist - es ist, weil es den Konventionen folgt, die ich gewohnt bin. Convention schlägt "besser" ...

Zusammen mit den anderen bereits erwähnten Nachteilen erhöht das Tabellenlayout die Wahrscheinlichkeit von Zusammenführungskonflikten der Versionskontrolle, die manuelles Eingreifen erfordern.

Wenn ein Block mit tabellarischem Code neu ausgerichtet werden muss, behandelt das Versionskontrollsystem jede dieser Zeilen als geändert:

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

Angenommen, in der Zwischenzeit hat ein Programmierer in einem anderen Zweig eine neue Zeile zum Block mit ausgerichtetem Code hinzugefügt:

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

Das Zusammenführen dieses Zweigs schlägt fehl:

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.

Wenn der zu ändernde Code keine tabellarische Ausrichtung verwendet hätte, wäre die Zusammenführung automatisch erfolgreich gewesen.

(Diese Antwort wurde aus meinem eigenen Artikel "plagiiert", wodurch die tabellarische Ausrichtung im Code erschwert wurde).

Tabellenformate können sehr schön sein, wenn die Dinge immer in die zugewiesene Breite passen. Wenn jedoch etwas die zugewiesene Breite überschreitet, ist es häufig erforderlich, entweder einen Teil der Tabelle zu haben, der nicht mit dem Rest der Tabelle ausgerichtet ist, oder das Layout aller anderen Teile der Tabelle so anzupassen, dass sie zum langen Artikel passen .

Wenn Quelldateien mit Programmen bearbeitet wurden, die für die Arbeit mit Daten im Tabellenformat entwickelt wurden und übermäßig lange Elemente mit einer kleineren Schriftgröße verarbeiten konnten, indem sie in zwei Zeilen in derselben Zelle usw. aufgeteilt wurden, ist die Verwendung von Tabellen möglicherweise sinnvoll formatiert häufiger, aber die meisten Compiler möchten Quelldateien, die frei von Markups sind, die solche Editoren speichern müssten, um die Formatierung beizubehalten. Die Verwendung von Zeilen mit variablen Einzügen, aber keinem anderen Layout ist im besten Fall nicht so gut wie die Formatierung von Tabellen, im schlimmsten Fall verursacht sie jedoch nicht annähernd so viele Probleme.

Es gibt die "switch" -Anweisung, die diese Art von Dingen für Sonderfälle bereitstellt, aber ich denke, das ist nicht das, wonach Sie fragen.

Ich habe gesehen, ob Anweisungen im Tabellenformat, aber es muss eine große Anzahl von Bedingungen geben, damit es sich lohnt. 3 Wenn Anweisungen am besten im herkömmlichen Format angezeigt werden, aber wenn Sie 20 hatten, ist es viel einfacher, sie in einem großen Block anzuzeigen, der zur Verdeutlichung formatiert ist.

Und da ist der Punkt: Klarheit. Wenn dies die Anzeige erleichtert (und Ihr erstes Beispiel nicht leicht erkennen lässt, wo sich das Trennzeichen befindet), formatieren Sie es entsprechend der jeweiligen Situation. Ansonsten bleiben Sie bei dem, was die Leute erwarten, denn das ist immer leichter zu erkennen.

Wenn Ihr Ausdruck wirklich so einfach ist, bieten die meisten Programmiersprachen den Verzweigungsoperator?::

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

Dies ist ein kurzes, lesbares Tabellenformat. Aber das Wichtige ist: Ich sehe auf einen Blick, was die "Hauptaktion" ist. Dies ist eine Rückgabeerklärung! Und der Wert wird von bestimmten Bedingungen bestimmt.

Wenn Sie andererseits Zweige haben, die anderen Code ausführen, finde ich es viel lesbarer, diese Blöcke einzurücken. Denn jetzt gibt es je nach if-Anweisung unterschiedliche "Hauptaktionen". In einem Fall werfen wir, in einem Fall loggen wir uns ein und kehren zurück oder kehren einfach zurück. Abhängig von der Logik gibt es einen unterschiedlichen Programmfluss. Daher kapseln Codeblöcke die verschiedenen Zweige und machen sie für den Entwickler bekannter (z. B. Geschwindigkeitslesen einer Funktion zum Erfassen des Programmflusses).

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

Wie Enderland bereits sagte, gehen Sie davon aus, dass Sie immer nur ein "Return" als Aktion haben und dass Sie dieses "Return" am Ende der Bedingung markieren können. Ich möchte einige zusätzliche Details nennen, warum dies nicht erfolgreich sein wird.

Ich weiß nicht, welche Sprachen Sie bevorzugen, aber ich habe lange Zeit in C codiert. Es gibt eine Reihe von Codierungsstandards, die darauf abzielen, einige Standardcodierungsfehler zu vermeiden, indem fehleranfällige Codekonstruktionen weder bei der Erstcodierung noch bei der späteren Wartung zugelassen werden. Ich kenne MISRA-C am besten, aber es gibt andere, und im Allgemeinen haben sie alle ähnliche Regeln, weil sie dieselben Probleme in derselben Sprache ansprechen.

Ein beliebter Fehler, den Codierungsstandards häufig ansprechen, ist dieses kleine Problem:

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

Das tut nicht das, was du denkst. Für C gilt: Wenn x 10 ist, dann rufst du do_something(), wird dann do_something_else()aber unabhängig vom Wert von x gerufen . Nur die unmittelbar auf die "if" -Anweisung folgende Aktion ist bedingt. Dies könnte das sein, was der Codierer beabsichtigt hat. In diesem Fall gibt es eine potenzielle Falle für Betreuer. oder es ist nicht das, was der Codierer beabsichtigt hat. In diesem Fall liegt ein Fehler vor. Es ist eine beliebte Interviewfrage.

Die Lösung für Codierungsstandards besteht darin, alle bedingten Aktionen in geschweiften Klammern zu setzen, auch wenn sie einzeilig sind. Wir bekommen jetzt

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

oder

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

und jetzt funktioniert es richtig und ist für Betreuer klar.

Sie werden feststellen, dass dies nicht mit Ihrem Tabellenformat kompatibel ist.

Einige andere Sprachen (z. B. Python) haben sich mit diesem Problem befasst und entschieden, dass es eine gute Idee ist, anstelle von geschweiften Klammern Leerzeichen zu verwenden, da Codierer Leerzeichen verwenden, um das Layout zu verdeutlichen. Also in Python,

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

macht die Aufrufe von beiden do_something()und do_something_else()von x == 10 abhängig, wohingegen

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

bedeutet, dass nur do_something()an x gebunden ist und do_something_else()immer aufgerufen wird.

Es ist ein gültiges Konzept und wird von einigen Sprachen verwendet. (Ich habe es zum ersten Mal in Occam2 gesehen, vor langer Zeit.) Auch hier können Sie leicht feststellen, dass Ihr Tabellenformat nicht mit der Sprache kompatibel ist.

Das tabellarische Layout kann in einigen wenigen Fällen hilfreich sein, in einigen Fällen ist es jedoch hilfreich, wenn.

In einfachen Fällen?: Kann eine bessere Wahl sein. In mittleren Fällen passt ein Schalter oft besser (wenn Ihre Sprache einen hat). In komplizierten Fällen stellen Sie möglicherweise fest, dass Aufruftabellen besser passen.

Es gab viele Male, als ich Code umgestaltete, um es tabellarisch darzustellen, damit es offensichtlich wird. Es ist selten der Fall, dass ich es so lasse, da es in den meisten Fällen einen besseren Weg gibt, das Problem zu lösen, sobald Sie es verstanden haben. Gelegentlich verbietet eine Codierungspraxis oder ein Layoutstandard dies. In diesem Fall ist ein Kommentar hilfreich.

Es gab einige Fragen zu ?:. Ja, es ist der ternäre Operator (oder, wie ich finde, der Wert, wenn). Beim ersten Erröten ist dieses Beispiel ein wenig kompliziert für?: (und übermäßiges Verwenden?: hilft der Lesbarkeit nicht, schadet aber), aber mit einigem Nachdenken. Das Beispiel kann wie folgt umgestellt werden Lösung.

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

Ich sehe nichts falsch mit dem Tabellenformat. Persönliche Präferenz, aber ich würde einen Ternären wie diesen verwenden:

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

Keine Notwendigkeit, returnjedes Mal zu wiederholen :)