1) Ich weiß, wie if…else if Anweisungen funktionieren, aber im nächsten Beispiel sind beide Methoden identisch, was den resultierenden Wert betrifft. Es spielt also eine Rolle, welche der beiden Methoden ich verwende oder sollte ich immer diejenige wählen, die dem Code, den der Code versucht, semantisch am nächsten kommt (hier vermute ich, dass die beiden Methoden semantisch recht unterschiedlich sind)? Also welche Methode würdest du benutzen und warum?
2) Ich bemerkte, dass Code-Verluste beim Schreiben von if ... else if -Anweisungen das folgende Format verwenden:
Aber ist nicht (zumindest konzeptionell) richtiger:
%Vor%Die Frage ist bereits beantwortet, aber ich habe das hinzugefügt, weil:
Bearbeitet zum Hinzufügen:
Ich bin normalerweise ein großer Fan davon, eine Funktion in solchen Fällen früh zu beenden:
%Vor%Ich bin viel glücklicher, das zu sehen:
%Vor%Aber wenn es bei viele verschiedene Verschachtelungsebenen gibt , ist es zu einfach, eine zu verpassen, wenn Sie den Code überlesen.
Auch, wie in den Kommentaren erwähnt: Ein einzelner Ausgang bedeutet nur einen Platz, um einen Haltepunkt zu setzen.
Wenn die Bedingungen sich gegenseitig ausschließen, dann denke ich ein anderes wenn Muster am besten ist. Es wird schwieriger sein, versehentlich zu brechen, wenn sich der Code entwickelt und komplexer wird, weil Ihr Kontrollfluss die gegenseitige Exklusivität der Logik genauer repräsentiert.
Überlegen Sie, ob jemand Ihr erstes Beispiel so umgestaltet hat, dass es dem Beispiel von egrunin ähnelt, so dass es nur eine Rückgabe gibt, aber vergessen Sie, das "else" zu jedem if hinzuzufügen:
%Vor%Sie haben gerade einen Fehler eingeführt. Sie haben vielleicht nicht erkannt, dass die Renditen Teil der ausgedrückten Logik waren. Während der Fehler hier offensichtlich ist, könnte dieser Code ein paar Jahre später im realen Leben möglicherweise komplexer, langwieriger und schwieriger zu lesen sein, so dass es einfacher ist, einen solchen Fehler zu machen.
Erkennung eines unerwarteten Fehlers
Zusätzlich, wenn mindestens eine Bedingung erfüllt sein muss (d. h., sollte niemals eine leere Zeichenkette zurückgeben), würde ich eine Ausnahme im letzten else werfen, wenn Sie annehmen, dass alle Fälle behandelt werden sollten. Dies würde einen Fehler im Code erkennen, bei dem der Code durch alle Elemente fiel und keine übereinstimmende Bedingung gefunden wurde. Wenn Sie keine Ausnahme auslösen, kann der Fehler seltsames Verhalten verursachen. Wie behandelt der Rest des Codes die nicht initialisierte leere Zeichenfolge? Hängt stark vom Code ab. Die Idee des Auslösens einer Ausnahme besteht darin, einen Fehler genau dort zu verursachen, wo der Fehler auftritt, so dass er leicht identifiziert und korrigiert werden kann, anstatt zuzulassen, dass die Anwendung mit einer ungültigen Rückgabe weiterläuft.
%Vor%Wenn Sie mit einer geeigneten Protokollierung / Benachrichtigung für die Ausnahmebedingungen gepaart sind, können Sie auf diesen Fehler aufmerksam werden und eine Bedingung hinzufügen, um unvorhergesehene Werte zu behandeln. Nicht wirklich notwendig für sehr einfache Bedingungen, aber sehr hilfreich beim proaktiven Finden und Korrigieren von Fehlern in dieser Art von Code.
Sie sind semantisch identisch. Ich bezweifle, dass es einen Unterschied in der Leistung gibt, also ist die Wahl über Stil und Lesbarkeit. Wenn Sie neugierig sind, kompilieren Sie den obigen Code in eine Assembly und verwenden Sie Reflektor , um festzustellen, ob ein Unterschied besteht in der IL. Meine Vermutung ist, es gäbe wenig Unterschied wenn überhaupt.
Es ist meistens eine Frage der Präferenz. Bei der Verwendung von return statements brauchen Sie meines Erachtens nicht die ellen, da klar ist, dass die Funktion genau dort endet. Es hängt alles sehr von der Situation und dem Stil ab, daher gibt es keinen klaren "besten" Weg, dies zu tun.
Ich würde Ersteres vorschlagen, da Sie eine logische Wahl zwischen vier Möglichkeiten treffen. Sie gruppieren die Entscheidung in einem if / else if-Block.
Wenn Sie die Entscheidungen wie in Ihrer zweiten Funktion trennen, scheinen sie überhaupt nicht verbunden zu sein. Offensichtlich sind sie, wie die Wertvariable wiederholt wird, aber es muss nicht unbedingt offensichtlich sein.
Wenn Sie nichts zurückgeben können, geben Sie bitte null und keine leere Zeichenfolge zurück. In einer Anwendung, die ich pflege, ist es immer noch notwendig, if (Wert == null || value!="").
Sie möchten "else if" verwenden, da das nur dann ausgelöst wird, wenn das erste "if" nicht akzeptiert wird. In Ihrem Fall sind die 3 if-Anweisungen in Ordnung, einfach weil, wenn ein letzter "if" korrekt ist, dann die vorherigen "if" s nicht sein können.
In einem Fall, in dem alle Ihre if-Anweisungen korrekt sein könnten, möchten Sie else if.
verwendenZum Beispiel:
%Vor%Das ist ein sehr simples Beispiel, aber Sie bekommen die Idee. Sie verwenden "else if", wenn nur eine "if" -Anweisung ausgelöst werden soll.
Ich würde die erste Option verwenden, da es im Code zeigt, dass die Vergleiche "gruppiert" sind. Für 2 glaube ich, dass sie in genau demselben IL-Code enden.
Ich stelle immer sicher, dass der häufigste Senario zuerst in der if..else-Anweisung steht, da dies für die Leistung am besten ist.
Die Alternativen sind semantisch ziemlich nah, also spielt es keine Rolle. Wie in einigen Antworten vorgeschlagen, könnte das Ergebnis in eine String-Variable und die Rückgabe am Ende besser darstellen, was Sie in der Methode tun.
Eine andere Alternative ist die Verwendung des bedingten Operanden, der Ihnen einen weniger ausführlichen Code gibt:
%Vor% Mit den return -Anweisungen ist es wirklich egal. Ich stimme überhaupt nicht mit denen überein, die sagen, dass der zweite in irgendeiner Weise schlimmer ist. Was macht es schlimmer?
Als Antwort auf Ihre zweite Frage: Sie haben vollkommen recht. In der Tat sind nicht nur die beiden Möglichkeiten, if / else if effektiv zu formatieren gleich; Sie sind tatsächlich wörtlich gleich. C # erzwingt keinen bestimmten Formatierungsstil, daher sind alle identisch:
Alles, was Sie brauchen, ist Ihre Logik zu verstecken. Nimm das nicht zu ernst, aber ... ich würde es so machen. Ich weiß, deine Frage ist hier nicht beantwortet, aber es gibt schon genug wenn / dann / else Beispiele in diesem Thema.
1) Der erste ist häufiger und in der Praxis üblich. Es wäre also ratsam, sich an die Standardpraxis zu halten.
2) Im Allgemeinen, wenn mehr als eine bedingte Anweisung vorliegt, wird else if in den bedingten Zwischenausgaben verwendet und ansonsten in der letzten bedingten Ausgabe. Außerdem könnte es effizienter sein, da ich glaube, dass es nicht immer die gleiche Bedingung überprüfen muss, im Gegensatz zum if-else-if-else ... -Typ.
Es ist mehr wie eine Wahl, die Ihnen zur Verfügung gestellt wird, wo Sie Ihre eigenen aus vielen Wegen finden, die zum selben Bestimmungsort gehen. Aber die Wahl, die Sie oft hören oder sehen, ist die, die aufgrund der Erfahrung vieler Benutzer und Experten beliebt ist.
Ich würde sagen, die erste zu verwenden, wenn man annimmt, dass die Funktion eine von vier Möglichkeiten zurückgibt, die alle als "erfolgreich" gelten. Ich würde den letzteren Stil verwenden, wenn einige Rückgaben als "Fehler" bezeichnet werden. Zum Beispiel (Spielzeugbeispiel - Werfen könnte für die Fehlerfälle besser sein):
%Vor%Aus meiner Sicht wären das diese Prioritäten von oben bis unten.
Funktionalität / Erreichen des Endziels Reduzierung der Kosten in jedem Umfang / Ebene Lesbarkeit
^^^^ Beachten Sie, dass viele dies auf meiner Liste bestreiten und die Lesbarkeit über die Reduzierung der Kosten hinaus ansprechen, es hängt wirklich von Ihrer Arbeit envi ab. und das Endziel, aber ich finde das am häufigsten. Aber rate mal von einem Rookie, der nicht viel bedeutet, huh: D
Danach sind es ziemlich viele Erdnüsse. Gleiches gilt für? : Operator. Wenn Sie überzeugt sind, dass es besser lesbar ist, sollten Sie es tun. Funktional ist es nicht wirklich wichtig. Aber wenn () {} else {} unterscheidet sich deutlich von if () {} else if () {} Also wähle, was der optimale Code ist (Höchste gewünschte Ergebnisse minus unerwartete Ergebnisse - 0,5 * Lesbarkeits-Score) so ziemlich, was ich gehen würde auf.
Nun, da der Code das gleiche für Sie tut, kommt ein neues Attribut ins Spiel, wird dieser Code zu einem späteren Zeitpunkt bearbeitet? Und wenn ja, was wäre dann am besten? Vergiss nicht die Zukunft des Codes, noch die Kommentare, dass ein Gratisbonus mit dabei ist. Sie können beides auch tun, wenn Sie es für die Zeit nicht herausfinden und nur den anderen kommentieren, aber das hinterlässt schlampige Textwände, die später bei der Säuberung / Veröffentlichung entfernt werden.
Für das Beispiel, das zur Verfügung gestellt wird, müssen Sie sich nicht um "wenn" Aussagen kümmern, wenn Sie bereit sind, eine Menge Lesbarkeit und möglicherweise ein wenig Geschwindigkeit zu opfern:
%Vor%Nun, in Ihrem speziellen Fall würde ich Folgendes vorschlagen:
%Vor%}
Da Sie von der Funktion auf eine der wahren Bedingungen zurückkommen, müssen Sie 'else if' nicht mehr verwenden. Im Allgemeinen wird "else if" verwendet, wenn sich die beiden Bedingungen nicht gegenseitig ausschließen, was hier nicht der Fall ist. In diesem Fall wird der Code nicht weiter ausgeführt, wenn eine der Bedingungen zutrifft. Außerdem wird das letzte 'else' nicht benötigt, da die Steuerung diesen Punkt nur dann erreicht, wenn alle obigen Bedingungen falsch waren.
Es hängt alles davon ab, wo Sie es verwenden und wie. Das Hauptmotiv ist, die Lesbarkeit Ihres Codes zu maximieren und ihn so elegant und verständlich wie möglich zu gestalten.
Tags und Links c# coding-style