Ist es notwendig zu schreiben, else-Teil in jeder if-Bedingung?
Die Frage, die ich geschlossen werden könnte, Aber ich will einfach nur wissen, dass es notwendig ist zu schreiben, sonst Teil von jeder if-Bedingung. Einer meiner senior-Programmierer sagte mir, dass "Sie sollte schreiben else-Teil in jeder if-Bedingung" . Nehmen wir an, wir haben keine Bedingung für das schreiben in else-Teil dann, was sollen wir tun ? Ich nehme an, eine gesunde Diskussion hier Los....
Ich versuche, nicht zu "soll" auf meine Kollegen. Es neigt dazu, sich chaotisch. Verwenden Sie ein anderes nur, wenn es Sinn macht.
"wenn" Sie hört immer auf Ihre co-Arbeitskräfte, Holen Sie Ihre schlechten Gewohnheiten. Es gibt keine Notwendigkeit, zu sagen, " 'anderes' erhalten Sie für sich selbst zu lernen".
Ich denke, dass Ihr senior Programmierer tatsächlich gesagt, "Sie sollten darüber nachdenken, wird der else-Teil in jeder if-Bedingung". Ich habe zu viel gesehen und fallen durch den code wegen fehlender else-Blöcken.
Scheint, wie hier eine bessere Antwort: stackoverflow.com/questions/35053371/...
"wenn" Sie hört immer auf Ihre co-Arbeitskräfte, Holen Sie Ihre schlechten Gewohnheiten. Es gibt keine Notwendigkeit, zu sagen, " 'anderes' erhalten Sie für sich selbst zu lernen".
Ich denke, dass Ihr senior Programmierer tatsächlich gesagt, "Sie sollten darüber nachdenken, wird der else-Teil in jeder if-Bedingung". Ich habe zu viel gesehen und fallen durch den code wegen fehlender else-Blöcken.
Scheint, wie hier eine bessere Antwort: stackoverflow.com/questions/35053371/...
InformationsquelleAutor Rahul Vyas | 2010-08-03
Du musst angemeldet sein, um einen Kommentar abzugeben.
Das ist eine schreckliche Idee. Sie enden mit einem code der form:
Wie jemand denken könnte, dass mehr lesbar oder wartbar zu sein, dass nicht mit einer
else
überhaupt ist mir schleierhaft. Es klingt wie eine von diesen Regeln, die von Menschen gebildet, die haben zu viel freie Zeit auf Ihre Hände. Erhalten Sie feuerte so schnell, wie Sie können, oder zumindest Weg bewegen, still und leise 🙂"One option is to code the else clause—with a null statement if necessary—to show that the else case has been considered. Coding null elses just to show that that case has been considered might be overkill, but at the very least, take the else case into account. When you have an if test without an else, unless the reason is obvious, use comments to explain why the else clause isn’t necessary." - Code Complete
Ich fühle mich im Zwiespalt, was denkst du ?Ich denke, wie so viel Zeug zitiert aus diesem Buch, muss es in Kontext: der vorhergehende Satz ist: "Wenn Sie denken, Sie brauchen eine Ebene
if
Anweisung betrachten ob Sie nicht wirklich benötigen eineif-then-else
Anweisung." Jeder wenig code, den ich Schreibe, ist das Ergebnis informiert überlegung so: nn diesem Fall abgelehnt, da eine anständige Programmierer wissen, dass eine fehlendeelse
- Klausel bedeutet, dass keine Maßnahmen ergriffen werden sollten. Ich lese keine Funktion und Wundern sich über die sieben Linien, die waren noch nie am Ende der es, das ist genau die Haltung, die Sie ergreifen sollten, um die fehlendenelse
🙂Das problem mit diesem tollen Buch ist, dass es sehr offensichtlich/beginnerish Aussagen, die von Zeit zu Zeit. E. g in der vorhergehenden Seite, es sagt
you should avoid 'if-then-else' statements where the 'if' block has no statements in its body and instead negate the test condition
(ich paraphrasiere).Nicht dass ich mich beschweren obwohl. Ich werde mich auf jeden Tag wählen Sie ein Buch, das die macht, offensichtliche Aussagen über eine davon enthält rätselhafte Unklarheiten, weil der Autor zog die Linie zwischen offensichtlich/nicht-offensichtliche (die vielleicht nie möglich sein in den ersten Platz, da hat jeder unterschiedliche Kenntnisse/Erfahrung) an der falschen Stelle.
InformationsquelleAutor paxdiablo
Nein, Sie sind sicherlich nicht haben - zumindest in den meisten Sprachen. (Du nicht angeben; es ist durchaus möglich, dass es eine Sprache, die hat diese durchzusetzen.) Hier ist ein Beispiel, wo ich bestimmt nicht:
Nun Sie könnte setzen die Hauptaufgabe der Methode in einem "else" - Klausel hier - aber es würde erhöhen unnötig verschachteln. Fügen Sie ein paar mehr Bedingungen und die ganze Sache wird ein unlesbares Chaos.
Dieses Muster der "early out" ist ziemlich verbreitet, in meiner Erfahrung - und gilt für Rückgabewerte sowie Ausnahmen. Ich weiß, es gibt einige, die zugunsten einer einzigen return-Punkt aus einer Methode, sondern in den Sprachen, mit denen ich arbeite (Java, C#), führen oft zu deutlich weniger lesbaren code und tiefer Verschachtelung zu.
Nun, es gibt eine situation, wo es mehr Spielraum für die Debatte, und das ist, wo beide Zweige sind terminal, aber keiner von Ihnen ist tatsächlich eine Abkürzung:
(Hinweis: ich habe bewusst beide Zweige mehr Arbeit zu tun, als einfach wieder - ansonsten eine bedingte Anweisung angemessen wäre.)
Wäre dies mehr lesbar, ohne das "else"? Das ist wirklich eine Angelegenheit der persönlichen Wahl, und ich werde nicht behaupten, ich bin immer konsistent. Nachdem beide äste gleichermaßen eingerückt, gibt Ihnen gleiche Gewicht irgendwie - und vielleicht ermutigt, die Möglichkeit von refactoring später durch die Umkehrung der Bedingung... wohingegen, wenn wir hatten, fiel nur durch den "zurück original-Preis", dem refactoring setzen, dass in ein if-block und verschieben Sie die Rabatt-Falle aus einer if-block wäre weniger offensichtlich, auf den ersten Blick richtig.
InformationsquelleAutor Jon Skeet
Gefahr! Gefahr, Will Robinson!
http://en.wikipedia.org/wiki/Cargo_cult_programming
Ist die Aufnahme von leeren
else { }
Blöcke irgendwie zu verbessern, die Qualität, Lesbarkeit oder Robustheit des Codes? Ich denke nicht.InformationsquelleAutor Dan J
In imperativen Sprachen wie Java und C
if - else
ist eine Erklärung und nicht einen Wert zurückgeben. So können Sie gerne schreiben nur dieif
Teil und gehen auf. Und ich denke, dass es die bessere Methode, anstatt das hinzufügen von leerelse
s nach jedemif
.Jedoch in funktionalen Sprachen wie Haskell und Clojure
if
ist ein Ausdruck, und es muss einen Wert zurückgeben. Also muss es gelungen, mit einemelse
. Allerdings gibt es immer noch Fälle, wo man nicht brauchen kann, einelse
Abschnitt. Clojure, für solche Fälle hat einwhen
makro, welches wrapsif - else
zurücknil
imelse
Abschnitt und vermeiden, es zu schreiben.if-else
expression.InformationsquelleAutor Abhinav Sarkar
Suchen auf diesem rein semantischen Standpunkt aus - ich kann mir nicht vorstellen, einen einzigen Fall
dort, wo es nicht eine implizite sonst für jeden wenn.
wenn das Auto ist nicht beendet, bevor ich erreichen die Wand ich werde Abstürzen, sonst werde ich nicht Abstürzen.
Semantik abgesehen:
Die Antwort auf diese Frage hängt von der Umgebung ab, und was das Ergebnis ein Fehler ist.
Business code? Tun Sie, was Ihre coding-standards sagen.
IMHO werden Sie feststellen, dass Rechtschreibung es aus, obwohl es anfangs scheint, wie zu viel Arbeit, wird von unschätzbarem Wert in 10 Jahren, wenn Sie noch einmal überdenken, code. Aber es wäre sicherlich nicht das Ende der Welt, wenn Sie fehlten, eine wichtige 'anti-Zustand'.
Jedoch: die Sicherheit, die Sicherheit oder das Leben von Kritischen code? Das ist eine andere Geschichte.
In diesem Fall möchten Sie zwei Dinge tun.
Zuerst:Lieber, als Prüfung für einen Fehler, Sie wollen zu beweisen, es ist nicht ein Fehler. Dies erfordert eine pessimistische Sicht auf die Einreise zu einem beliebigen Modul. Sie übernehmen alles, was falsch ist
bis Sie beweisen, dass es richtig ist.
Zweitens: im Leben entscheidend: wollen Sie sich NIE verletzt, ein patient.:
Oops. Ich habe vergessen zu setzen everyThingIsSafe falsch.
Die routine, die aufgerufen diese snippit ist jetzt gelogen. Hatte ich initialisiert evertThingIsSafe zu falsch - ich bin immer sicher, aber jetzt muss ich die else-Klausel, um anzugeben, dass es war nicht ein Fehler.
Und ja, ich könnte geändert haben, dies zu einem positiven test, aber dann brauche ich die anderen
behandeln Sie den Fehler.
Und ja, ich hätte zugewiesen everyThingIsSafe() die sofortige Rückgabe des Schecks.
Und dann getestet, das flag, um ein problem zu melden. Eine implizite anderes, warum nicht explizit genannt werden?
Streng genommen, die impliziten sonst stellt dies zumutbar ist.
Um eine FDA - /safety-auditor, vielleicht auch nicht.
Wenn es explizit ist, kann auf den test, dessen anderes, und dass ich behandelt beide Bedingungen deutlich.
Ich habe die Codierung für medizinische Geräte für 25 Jahre. In diesem Fall möchten Sie den anderen, Sie möchten die Standardeinstellung in den Fall, und Sie sind nie leer. Sie wollen genau wissen, was passieren wird, oder so nah wie Sie können. Denn mit Blick auf eine Bedingung könnte jemanden umbringen.
Nachschlagen Therac-25. 8 schwer verletzt. 3 tot.
InformationsquelleAutor baumann
Manchmal gibt es keinen else-Teil....und darunter ein leerer macht den code weniger lesbar, imho.
InformationsquelleAutor InsertNickHere
Nein, du musst nicht ..
Auch, ich glaube nicht, dass es eine gute Idee für die Lesbarkeit, da Sie viele leer sonst Blöcke. das wird nicht schön zu sehen.
InformationsquelleAutor Ahmed Aman
Dies ist rein eine Frage des Stils und Klarheit. Es ist leicht vorstellbar, wenn Aussagen, insbesondere einfache, für die eine andere wäre ziemlich überflüssig. Aber, wenn du eine komplexere bedingte, vielleicht Umgang mit einer Reihe von verschiedenen Fällen, ist es oft der Klärung explizit deklarieren, sonst nichts, was getan werden sollte. In diesen Fällen würde ich lassen eine
//do nothing
Kommentar in die-ansonsten leere-sonst ist es klar, dass der Raum absichtlich leer gelassen.InformationsquelleAutor Thom Smith
Nein, aber ich persönlich wähle immer auch den Verguss von Klammern zu vermeiden
Ich würde schreiben
Ich sollte gewesen klarer. Bearbeitet.
schöner Kompromiss
InformationsquelleAutor Laramie
Ich weiß, ich bin spät dran, aber ich habe viel nachgedacht über dies und wollte meine Ergebnisse.
In kritischen code, ist es unerlässlich für jeden Zweig entfallen. Schreiben, ein anderes ist nicht notwendig, aber hinterlassen Sie eine Marke, die sonst nicht notwendig ist und warum. Dies wird helfen, die reviewer. Beachten Sie:
InformationsquelleAutor Cem Kalyoncu