Hat / kann jemand Onkel Bob herausfordern, „unnütze Zahnspangen“ zu entfernen?

94

Ich hasse es, auf Paywall-Inhalte zu verweisen, aber dieses Video zeigt genau, wovon ich spreche. Genau 12 Minuten in Robert Martin sieht das so aus:

Ein bisschen Code

Und sagt: "Eine meiner Lieblingsbeschäftigungen ist es, nutzlose Zahnspangen loszuwerden."

Mehr Code

Vor langer Zeit, in einer weit entfernten Ausbildung, wurde mir beigebracht, dies nicht zu tun, weil es einfach ist, einen Fehler einzuführen, indem eine weitere eingerückte Zeile hinzugefügt wird, die denkt, dass sie durch das gesteuert wird, ifwenn es nicht ist.

Um Onkel Bob gegenüber fair zu sein, überarbeitet er eine lange Java-Methode auf winzige kleine Funktionen, die, da stimme ich zu, weitaus besser lesbar sind. Wenn er es geändert hat (22.18), sieht es so aus:

Noch mehr Code

Ich frage mich, ob das das Entfernen der Zahnspangen bestätigen soll. Ich bin bereits mit der Best Practice vertraut . Kann Onkel Bob in diesem Punkt herausgefordert werden? Hat Onkel Bob die Idee verteidigt?

kandierte_orange
quelle
6
Ich stimme dafür, diese Frage als "Off-Topic" zu schließen, da jede Antwort auf diese Frage "Nein" oder "Ja" lautet, und hier ist ein Zitat.
Blrfl
35
Geben Sie es ein paar Jahre, vielleicht wird er den nutzlosen Zeilenumbruch auch entfernen und "wenn (siehe (etwas)) sagen (etwas);" tatsächlich wird eine einzige Zeile Code ;-)
Steve Jessop
8
@SteveJessop Schön zu hören, dass ich Jahre voraus bin. : D Ohne die Newline besteht kein Risiko für den berüchtigten Bug. Das Hinzufügen / Entfernen von Klammern nach Bedarf ist ein zusätzlicher Aufwand, aber beim Lesen wird viel mehr gespart.
Maaartinus
9
Uncle Bob macht einige gute Punkte für es in Clean Code tun, Seite 35. Wenn ein ifBlock immer nur eine Zeile ist, spielt es keine Rolle. Wenn Sie mehr Zeilen hinzufügen müssen, sollte es eine andere Funktion sein, die den ifBlock zurück auf eine Zeile reduziert (der Funktionsaufruf). Wenn Sie sich daran halten, spielen Zahnspangen einfach keine Rolle - überhaupt nicht .
13
Er sollte es nur tun, return (page==null) ? "" : includePage(mode,page);wenn er so sehr darauf aus ist, knapp zu werden. Ich fand es cool, wenn man keine Klammer benutzt, bis ich anfing, Apps professionell zu entwickeln. Diff Noise, mögliche Tippfehler usw. Die Klammern, die die ganze Zeit da sind, sparen Ihnen Zeit und Overhead, die Sie später benötigen würden, um sie einzuführen.
Vaxquis

Antworten:

47

Lesbarkeit ist keine Kleinigkeit.

Ich bin gemischter Meinung, wenn es um Zahnspangen geht, die eine einzige Methode umfassen. Ich persönlich entferne sie für Dinge wie einzeilige Return-Anweisungen, aber das Weglassen solcher Klammern hat uns an der letzten Stelle, an der ich gearbeitet habe, wirklich sehr gebissen. Jemand fügte einer ifAnweisung eine Codezeile hinzu, ohne die erforderlichen geschweiften Klammern einzufügen, und da es sich um C handelte, stürzte das System ohne Vorwarnung ab.

Ich fordere niemanden heraus, der religiös ist, nach diesem kleinen Fiasko immer Zahnspangen zu tragen.

Ich sehe also den Vorteil der Lesbarkeit, bin mir aber der Probleme sehr bewusst, die auftreten können, wenn Sie diese Klammern weglassen.

Ich würde nicht versuchen, eine Studie oder eine veröffentlichte Meinung von jemandem zu finden. Jeder hat eine (das heißt eine Meinung), und da es sich um eine stilistische Frage handelt, ist eine Meinung so gut wie jede andere. Denken Sie selbst über das Problem nach, bewerten Sie die Vor- und Nachteile und entscheiden Sie sich selbst. Wenn der Shop, für den Sie arbeiten, einen Kodierungsstandard hat, der dieses Problem abdeckt, befolgen Sie diesen einfach.

Robert Harvey
quelle
7
Das hat mich zu neulich gepackt, als die Einrückung nicht richtig und irreführend war.
Andy
12
Weil es C ohne GCC 6 war-Wmisleading-indentation .
Wchargin
2
@CandiedOrange: Es ist Onkel Bob, der das etablierte Dogma in Frage stellt.
Robert Harvey
1
@RobertHarvey Habe ich das nicht klargestellt? Ja, er fordert das Dogma heraus. Er fordert MEIN Dogma heraus. Ich versuche nur ein guter Schüler zu sein und denke zumindest darüber nach. Aber Onkel Bob ist so verdammt charismatisch, dass ich mich frage, ob ich die Objektivität verliere. Also bitte ich um Hilfe, um ein Gegenmittel zu finden, bevor ich den Koolaid trinke.
candied_orange
1
@CandiedOrange: Es ist absolut eine Kontextsache. Diejenigen, die das Dogma blind akzeptieren, berücksichtigen den Kontext nicht. Diese verwenden in verwalteten Sprachen immer noch die Regel "nur eine Rückgabe", lange nachdem die Regel ihre Nützlichkeit überlebt hat und tatsächlich zu einem Hindernis geworden ist.
Robert Harvey
133

Sie finden hier oder hier oder überall dort, wo Fahrradschuppen lackiert sind, mehrere veröffentlichte Werbeaktionen oder Ablehnungen von No-Brace-Modellen .

Erinnern Sie sich an den großen OS X / iOS SSL-Fehler von 2014, als Sie sich vom Fahrradschuppen verabschiedeten ?

if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
    goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
    goto fail;
    goto fail;
if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
    goto fail;

Ja, "verursacht" durch nicht geschweifte Blöcke https://www.imperialviolet.org/2014/02/22/applebug.html

Die Einstellungen hängen möglicherweise vom Stil der geschweiften Klammer ab. Wenn ich schreiben müsste

if (suiteSetup)
{
    includePage(mode, suiteSetup);
}

Ich könnte auch geneigt sein, Platz zu sparen. Aber

if (suiteSetup) {
    includePage(mode, suiteSetup);
}

Verwendet nur eine "zusätzliche" Zeile.


Ich weiß, dass Sie nicht gefragt haben, aber wenn ich alleine arbeite, bin ich ein Ketzer. Wenn ich Klammern entferne, bevorzuge ich

if (suiteSetup != null) includePage(mode, suiteSetup);

Es hat nicht das gleiche visuelle Problem wie der Fehler im SSL-Stil von iOS, spart jedoch noch mehr "unnötige" Zeilen als Onkel Bob;) Liest gut, wenn Sie daran gewöhnt sind, und verwendet den Mainstream in Ruby ( includePage(mode, suiteSetup) unless suiteSetup.nil?). Na ja, wisst einfach, dass es viele Meinungen gibt.

Paul Draper
quelle
13
Wenn Sie diese Option verwenden } else[if(...)] {, werden keine zusätzlichen Zeilen hinzugefügt, sodass das Ganze nur um eine Zeile länger ist.
Random832
12
Ich bin froh, dass Sie den iOS SSL-Fehler melden. Seitdem benutze ich in solchen Situationen immer häufiger Zahnspangen.
Zach Lipton
4
In Bezug auf den Fehler "goto fail" ist anzumerken, dass andere Aspekte des Codierungsstils von Onkel Bob dies ebenfalls verhindert hätten, vor allem seine starke Vorliebe für extrem kurze Methoden. Er hätte niemals eine 79-Zeilen-Methode geduldet, und wäre die Methode in kleinere unterteilt worden (a), wäre der Zusammenführungskonflikt, der die Duplizierung verursacht hat, wahrscheinlich niemals aufgetreten, und (b) die einfachere Ablaufsteuerung in der Methode Dies hätte wahrscheinlich dazu geführt, dass Compiler-Warnungen für nicht erreichbaren Code generiert wurden, die das Problem hätten verhindern sollen.
Jules
16
"goto fail" wurde nicht durch einzelne Zeilenblöcke verursacht, sondern durch schlampige Programmierung, noch schlampigere Codeüberprüfung und nicht einmal manuelles Durchlaufen des Codes.
gnasher729
35
Meh, das Fehlen von Zahnspangen hat diesen Fehler nicht verursacht. Entsetzliche Programmierer (und keine aussagekräftigen Codeüberprüfungen, Tests) haben es getan. Beheben Sie das Problem, indem Sie die Verantwortlichen entlassen und nicht die Hände des Restes von uns binden!
Leichtigkeit Rennen im Orbit
62

Onkel Bob hat viele Abwehrmechanismen gegen einen solchen Fehler, der nicht alltäglich war, als "immer geschweifte Klammern verwenden" die vorherrschende Weisheit war:

  1. Eine starke persönliche Vorliebe für einzeilige Bedingungen, sodass mehrzeilige hervorstechen und zusätzliche Aufmerksamkeit erhalten.
  2. Ein Editor, der beim Einfügen einer zweiten Zeile automatisch ausrückt.
  3. Eine komplette Reihe von Unit-Tests, die er ständig durchführt.
  4. Eine vollständige Suite von Integrationstests.
  5. Eine Peer Review, die durchgeführt wurde, bevor sein Code eingearbeitet wurde.
  6. Eine Wiederholung aller Tests durch einen Continuous Integration Server.
  7. Prüfung durch eine Produktqualitätsabteilung.

Ich denke, wenn jemand eine Herausforderung an Onkel Bob veröffentlichen würde, hätte er eine ziemlich gute Gegenargumentation zu den oben genannten Punkten. Dies ist einer der einfachsten Fehler, die man früh fangen kann.

Karl Bielefeldt
quelle
16
Ich habe noch nie Crashs befürchtet, so wie ich Dinge befürchte, die lautlos scheitern. Zumindest wissen Sie, wann ein Absturz passiert. Die Rückseite meines Gehirns kribbelt, wenn ich dieses Zeug sehe. Es kribbelt genauso, wie ich es sehe while(true);{break;}. Wenn es wirklich einen gültigen Kontext dafür gibt, werde ich eine Weile brauchen, um darüber hinwegzukommen.
candied_orange
9
Haben wir eine automatisierte Methode zur Überprüfung, includePage()die kein schlecht geschriebenes Makro mit mehr als einer Anweisung ist?
Martin York
51
@LokiAstari Ja, es heißt "Java hat keine Makros".
Svick
11
All dies sind eher "Möglichkeiten, um zu vermeiden, dass die mit der Richtlinie" Unbrauchbare Klammern "verbundenen Nachteile mich verletzen" als "Gründe, die Richtlinie" Unbrauchbare Klammern "zu verwenden". Die Fakten, die Sie benötigen (insbesondere # 1), sollten eher als Nachteil als als Vorteil betrachtet werden.
SJuan76
16
@Jules Oh ja! ALLE Produkte, die ich bei der Arbeit erhalten oder freigegeben habe, haben (zumindest) eine 100% ige Testabdeckung, werden (mehrmals) von Fachleuten geprüft und alle Unternehmen in der Umgebung haben Software-QA-Abteilungen. Ja. Ich vermute, Sie haben in Ihrer beruflichen Laufbahn das Gleiche festgestellt, denn in jedem Unternehmen gibt es Teams von Programmierern anstelle von einzelnen Programmierern, die ihnen mehr als genug Zeit geben, um alle gewünschten Tests durchzuführen. Ja, das beschreibt alle Arbeitsplätze perfekt. Warum sollten Sie sich Gedanken über das Hinzufügen zusätzlicher Fehler machen, wenn wir sicher sind, dass unsere Software IMMER 100% fehlerfrei ist?
SJuan76
31

Meistens ist dies eine persönliche Präferenz, es gibt jedoch einige Dinge zu beachten.

Mögliche Bugs

Während es kann argumentiert werden , dass durch Vergessen verursacht Bugs Klammern selten sind Add-in, von dem, was ich habe gesehen , dass sie es passieren gelegentlich (nicht das berühmte zu vergessen IOS gehe fehl Fehler). Ich denke, dies sollte ein Faktor sein, wenn Sie Ihren Codestil berücksichtigen (einige Tools warnen vor irreführenden Einrückungen , daher hängt dies auch von Ihrer Toolkette ab) .

Gültige - Code (das heißt , wie es könnte ein Fehler sein)

Auch Ihr Projekt unter der Annahme nicht von einem solchen Fehler leiden, wenn Codelese können Sie einige Code - Blöcke sehen , dass sie aussehen könnten Fehler sein - aber nicht, einige Ihrer mentalen Zyklen nehmen.

Wir beginnen mit:

if (foo)
    bar();

Ein Entwickler fügt einen nützlichen Kommentar hinzu.

if (foo)
    // At this point we know foo is valid.
    bar();

Später erweitert ein Entwickler es.

if (foo)
    // At this point we know foo is valid.
    // This never fails but is too slow even for debug, so keep disabled.
    // assert(is_valid(foo));
    bar();

Oder fügt einen verschachtelten Block hinzu:

if (foo)
    while (i--) {
        bar(i);
        baz(i);
    }

Oder benutzt ein Makro:

if (foo)
    SOME_MACRO();

"... Da Makros möglicherweise mehrere Codezeilen definieren, wird das Makro do {...} while (0)für mehrere Zeilen verwendet? Es sollte, weil es in unserem Style-Guide steht, aber ich überprüfe es besser nur für den Fall!"


Die obigen Beispiele sind alle gültiger Code. Je mehr Inhalt der Codeblock enthält, desto mehr muss gelesen werden, um sicherzustellen, dass keine Fehler vorliegen.

Vielleicht definiert Ihr Codestil, dass mehrzeilige Blöcke eine geschweifte Klammer erfordern (egal, ob sie Code sind oder nicht) , aber ich habe gesehen, dass diese Art von Kommentaren im Produktionscode hinzugefügt wurde. Wenn Sie es lesen, gibt es einen kleinen Zweifel, dass derjenige, der diese Zeilen zuletzt bearbeitet hat, vergessen hat, eine geschweifte Klammer hinzuzufügen. Manchmal habe ich das Gefühl, dass die Überprüfung wie beabsichtigt funktioniert (insbesondere, wenn ein Fehler in diesem Bereich des Codes untersucht wird) .

Diff Noise

Ein praktischer Grund für die Verwendung von geschweiften Klammern für einzelne Linien ist die Reduzierung des Diff-Rauschens .

Das heißt, ändern:

if (foo)
    bar();

Zu:

if (foo) {
    bar();
    baz();
}

... bewirkt, dass die bedingte Zeile in einem Diff als geändert angezeigt wird. Dies fügt einen kleinen, aber unnötigen Overhead hinzu.

  • Die Zeilen werden in Code-Überprüfungen als geändert angezeigt. Wenn Ihre abweichenden Tools wortbasiert sind, können Sie leicht feststellen, dass sich nur die geschweiften Klammern geändert haben. Die Überprüfung, ob sich die Zeile überhaupt nicht geändert hat, dauert jedoch länger.
    Allerdings unterstützen nicht alle Werkzeuge das wortbasierte Vergleichen. Diff (svn, git, hg ... etc) wird so angezeigt, als ob sich die gesamte Zeile geändert hätte, selbst mit ausgefallenen Werkzeugen. Manchmal müssen Sie schnell über eine einfache Zeile schauen -basiertes Diff, um zu sehen, was sich geändert hat.
  • Anmerkungswerkzeuge (z. B. git blame) zeigen die Linie als geändert an, wodurch die Verfolgung des Ursprungs einer Linie mehr Schritte erfordert, um die tatsächliche Änderung zu ermitteln.

Diese sind beide klein und hängen davon ab, wie viel Zeit Sie für die Codeüberprüfung oder -verfolgung aufwenden, um geänderte Codezeilen festzuschreiben.

Eine spürbarere Schwierigkeit besteht darin, dass zusätzliche Zeilen in einem Diff geändert werden. Die höhere Wahrscheinlichkeit, dass sich der Code ändert, führt zu Konflikten, die zusammengeführt werden und manuell gelöst werden müssen .


Es gibt eine Ausnahme für Code-Basen, die {eine eigene Zeile haben - es ist kein Problem.

Das diff noise- Argument gilt nicht, wenn Sie in diesem Stil schreiben:

if (foo)
{
    bar();
    baz();
}

Dies ist jedoch keine so verbreitete Konvention, weshalb der Vollständigkeit halber hauptsächlich auf die Antwort verwiesen wird (es wird nicht vorgeschlagen, dass Projekte diesen Stil verwenden sollten) .

ideasman42
quelle
8
Ich mag das reduzierte diff-Rauschen, das ein klares Plus ist.
Martin York
2
Wenn nur jeder, der sauer auf JSON ist, auf diff noise Rücksicht nehmen würde! Ich sehe dich an, No-Last-Comma-Regel.
Roman Starkov
1
Huh, ich hatte den Vorteil des Diff-Noise- {on-its-own-Line-Stils nicht in Betracht gezogen . Ich hasse diesen Stil wirklich und mag es nicht, an Projekten zu arbeiten, bei denen dieser Stil erforderlich ist. Vielleicht finde ich es in diesem Sinne weniger frustrierend, so codieren zu müssen. Codedichte ist wichtig. Wenn Sie alle Funktionen Ihres Monitors auf einmal sehen können, können Sie das Ganze einfacher fassen. Ich mag es, Leerzeilen zwischen separaten Codeblöcken in einer Funktion zur besseren Lesbarkeit zu lassen (um verwandte Anweisungen zu gruppieren), und wenn ich gezwungen bin, an anderen Stellen Platz zu verschwenden, werden die beabsichtigten Pausen schwächer.
Peter Cordes
1
@peter-cordes, ebenfalls kein Fan von {-on-its-own-line-Stil, bezog es nur aus Gründen der Vollständigkeit der Antworten mit ein. Wie für Makros zu vertrauen zu verwenden do{}while(0), finde ich das Problem dabei ist , Sie können ihm vertrauen fast die ganze Zeit. Das Problem ist, dass es zu Unfällen kommen kann, Fehler durch Codeüberprüfung auftreten können ... und Fehler auftreten können, die sonst nicht aufgetreten wären.
ideasman42
2
Wenn wir mögliche Fehler auflisten, ist die Möglichkeit, einzelne Zeilen auszukommentieren, eine weitere gute Sache. Ich habe einen Fehler aufgespürt, der dadurch verursacht wurde, dass jemand den Text einer einzeiligen if-Anweisung blind auskommentierte. Die folgende Anweisung wurde dann bedingt und nicht unbedingt ausgeführt.
Eldritch Cheese
15

Vor Jahren wurde ich dazu gebracht, C-Code zu debuggen. Der Fehler war verrückt, schwer zu finden, aber irgendwann kam es zu einer Aussage wie:

if (debug)
   foo (4);

Und es stellte sich heraus, dass die Person, die es geschrieben hatte, fooein Makro definiert hatte . Ein Makro mit zwei Codezeilen. Und natürlich unterlag nur die erste dieser beiden Zeilen der if. (Die zweite Zeile wurde also bedingungslos ausgeführt.)

Dies mag absolut einzigartig für C und seinen Präprozessor sein - der vor dem Kompilieren Substitutionen ausführt - aber ich habe es nie vergessen. Diese Art von Dingen hinterlässt Spuren bei Ihnen und warum gehen Sie nicht auf Nummer sicher - besonders wenn Sie eine Vielzahl von Sprachen und Werkzeugketten verwenden und nicht sicher sein können, dass solche Spielereien anderswo nicht möglich sind?

Jetzt rücke ich ein und benutze Klammern anscheinend anders als alle anderen. Für eine einzelne Zeile ifwürde ich Folgendes tun:

if (debug) { foo (4); }

Daher sind keine zusätzlichen Zeilen erforderlich, um die geschweiften Klammern einzufügen.

Wayne
quelle
6
In diesem Fall ist derjenige schuld, der dieses Makro geschrieben hat.
gnasher729
6
Das korrekte Schreiben von C-Präprozessor-Makros ist möglicherweise nicht intuitiv, kann jedoch durchgeführt werden. Und es sollte getan werden, wie gnasher729 betont. Und Ihr Beispiel ist der Grund, warum jedes Makro, das mehr als eine Anweisung enthält, seinen Körper in eine do { ... } while(0)Schleife einschließen muss . Dies stellt nicht nur sicher, dass if()Anweisungen immer korrekt behandelt werden , sondern auch, dass das Semikolon am Ende der Anweisung korrekt verschluckt wird. Wer solche einfachen Regeln nicht kennt, sollte einfach keine Präprozessor-Makros schreiben. Die Verteidigung am aufrufenden Standort ist der falsche Ort für die Verteidigung.
cmaster
18
@cmaster: Stimmt, aber wie Makros (oder andere Sprachfunktionen) von anderen geschrieben werden, liegt außerhalb meiner Kontrolle. Wie ich Zahnspangen benutze, liegt in meiner Hand. Ich sage definitiv nicht, dass dies ein eiserner Grund ist, um Zahnspangen einzufügen, aber es ist etwas, das ich tun kann, um mich gegen die Fehler anderer Leute zu verteidigen, also tue ich es.
Wayne
@ gnasher729, wen interessiert es, ob jemand anderes schuld ist? Wenn Sie Codeüberprüfungen durchführen und einige vernünftige Codestandards befolgen, liegt dies möglicherweise auch an Ihrem Team. Und wenn es die Benutzer erreicht, werden sie die Organisation beschuldigen, fehlerhafte Software veröffentlicht zu haben.
ideasman42
1
Wer sich Makros ausgedacht hat, ist schuld.
Neme
14

"Onkel Bob" darf seine Meinung haben, Sie dürfen Ihre Meinung haben. Keine Notwendigkeit, ihn herauszufordern.

Wenn Sie sich an die Behörde wenden möchten, nehmen Sie Chris Lattner. In Swift, wenn Anweisungen ihre Klammern verlieren, aber immer mit geschweiften Klammern kommen. Keine Diskussion, es ist Teil der Sprache. Wenn also "Onkel Bob" anfängt, geschweifte Klammern zu entfernen, wird der Code nicht mehr kompiliert.

Es ist eine schlechte Angewohnheit, den Code eines anderen zu durchgehen und "nutzlose Klammern loszuwerden". Verursacht nur dann zusätzliche Arbeit, wenn der Code überprüft werden muss und unnötig Konflikte entstehen. Vielleicht ist "Onkel Bob" ein so unglaublich guter Programmierer, dass er keine Code-Reviews benötigt? Ich habe eine Woche meines Lebens verschwendet, weil ein Top-Programmierer "if (p! = NULL)" in "if (! P)" geändert hat, ohne eine Codeüberprüfung durchzuführen, die an der schlechtesten Stelle versteckt war.

Dies ist meist eine harmlose Stildebatte. Klammern haben den Vorteil, dass Sie eine weitere Codezeile einfügen können, ohne Klammern hinzuzufügen. Wie eine Protokollierungsanweisung oder ein Kommentar (wenn ein Kommentar gefolgt von einer Anweisung folgt, ist das einfach schrecklich). Aussage in der gleichen Zeile, als hätte sie den praktischen Nachteil, dass Sie Probleme mit vielen Debuggern haben. Aber mach was du willst.

gnasher729
quelle
1
Ich denke, es geht um "Herausfordern", weil UB (sic!) Seine Meinungen als Fakten präsentiert - zumindest kommt es mir so vor, wenn ich ihm zuhöre.
Vaxquis
3
Zu sagen, "Tu, was auch immer du willst", bedeutet, mit Onkel Bob darüber einverstanden zu sein, denn das ist es, was er argumentiert, "es ist egal". In vielen Sprachen ist dies kein Problem. Ich hatte vorher in all den Fällen gedacht, in denen es ein Problem ist, dass Sie IMMER Zahnspangen verwenden sollten, und hatte noch niemanden gesehen, der dies in Frage stellte. Hier ist Onkel Bob, der es in Frage stellt, und ich frage mich, ob er damit durchkommt, weil er mit so überarbeiteten Methoden arbeitet oder weil er voll davon ist. Ich hatte es nicht als harmlos angesehen, genau wegen der Art von Fehlern, die @PaulDraper in seiner Antwort erwähnt.
candied_orange
Zu jeder Zeit : Das syntaktische Rauschen lenkt ab, und die zusätzliche "leere" Zeile für die schließende Klammer fügt ein visuelles Trennzeichen in den Absatz ein, in dem die Zeilen nicht getrennt werden sollten, wodurch die Lesbarkeit weiter beeinträchtigt wird. Dies ist besonders wichtig bei kleinen Blöcken, die Sie erwähnen.
JDługosz
9

Meine Gründe dafür, keine Zahnspange zu entfernen, sind:

  1. Entscheidungsermüdung reduzieren. Wenn Sie immer Zahnspangen verwenden, müssen Sie sich nie entscheiden, ob Sie Zahnspangen benötigen oder nicht.

  2. Entwicklung Widerstand verringern: auch wenn Sie danach streben, schließlich alle mehrzeiligen Logik Methoden zu extrahieren, eine ohne Verspannung , wenn zu einer verspannten umwandeln zu müssen , wenn hinzufügen Logik ist eine lästige bisschen Entwicklung ziehen. Sie müssen also die geschweiften Klammern entfernen und sie erneut hinzufügen, wenn Sie mehr Code benötigen. Winzig, aber nervig.

Michael Johnston
quelle
0

Ein junger Mitarbeiter hat gesagt, dass die Zahnspangen, die wir für überflüssig und überflüssig halten, ihm tatsächlich helfen. Ich erinnere mich nicht genau, warum, aber wenn es ihm erlaubt, besseren Code schneller zu schreiben, ist das allein ein Grund, sie zu behalten.

Fwiw, wir haben uns auf einen Kompromiss geeinigt, der besagt, dass es für mich keine so kurzen Voraussetzungen gibt, die nicht lesbar / ablenkend sind. Z.B

if (!param) { throw invalid_argument (blahblah); }
if (n < 2) { return 0; }
// real code for function starts here...

Ich weise auch darauf hin, dass diese einleitenden Voraussetzungen häufig Kontrollfluss-Anweisungen für den Körper sind (z. B. a return), sodass die Angst, eine zweite Anweisung hinzuzufügen, die unter derselben Bedingung stehen soll, und das Vergessen, geschweifte Klammern zu schreiben, umstritten ist. Eine zweite Aussage unter der Bedingung wäre sowieso toter Code und nicht sinnvoll.

Ich vermute, dass die fließende Lesefunktion darauf zurückzuführen ist, dass der Gehirnanalysator der Person so verdrahtet ist, dass er die geschweiften Klammern als Teil der bedingten Anweisung enthält. Dies ist keine exakte Darstellung der Grammatik von C ++, könnte jedoch ein Nebeneffekt beim Erlernen bestimmter anderer Sprachen sein, wenn dies der Fall ist.

JDługosz
quelle
1
Onkel Bob glaubt wahrscheinlich, dass er ohne sie schneller besseren Code schreibt.
Djechlin
2
Ich und andere sprechen fließend C ++.
JDługosz
1
"Wenn es ihm erlaubt, besseren Code schneller zu schreiben, ist das allein ein Grund, sie zu behalten." ++ Ich habe einen Junior, der das Gleiche sagte, also behalten wir sie.
RubberDuck
... und das ist nur ein Grund, es so zu machen, wie es Onkel Bob will.
Djechlin
-1

Nachdem ich das Video gerade gesehen hatte, bemerkte ich, dass das Eliminieren von geschweiften Klammern es einfacher macht zu erkennen, wo Code noch überarbeitet werden muss. Wenn Sie geschweifte Klammern benötigen, kann Ihr Code möglicherweise etwas sauberer sein.

Wenn Sie jedoch in einem Team sind, wird das Eliminieren von Zahnspangen wahrscheinlich eines Tages zu unerwartetem Verhalten führen. Ich sage, behalte sie, und du ersparst dir viele Kopfschmerzen, wenn etwas schief geht.

Gijs Overvliet
quelle
dies scheint nicht alles zu bieten erhebliche über Punkte gemacht und erläutert vor 10 Antworten
gnat
-3

Mir wurde beigebracht, dies nicht zu tun, da es einfach ist, einen Fehler einzuführen, indem eine weitere eingerückte Zeile hinzugefügt wird, die denkt, sie wird vom if gesteuert, wenn es nicht der Fall ist.

Wenn Ihr Code gut Unit-getestet ist , würde diese Art von "Fehler" im Gesicht explodieren.

Das Bereinigen des Codes durch Vermeiden nutzloser und hässlicher Klammern ist eine Praxis, der ich folge.

Mik378
quelle
9
Natürlich ist auch das Gegenteil der Fall: Wenn Ihr Code fehlerfrei ist, brauchen Sie keine Unit-Tests. Die Realität ist, dass wir in einer unvollkommenen Welt leben, in der es manchmal Fehler im Code und manchmal Fehler in Tests gibt. (Nach meiner Erfahrung sind letztere häufiger anzutreffen.) Tests verringern zwar das Risiko von Fehlern, dies ist jedoch keine Entschuldigung für die Suche nach anderen Möglichkeiten, um das Risiko sofort wieder zu erhöhen.
Ruakh
3
Hinzufügen zu Ruakhs Kommentar: Es ist nicht möglich, einen Code zu 100% in einer Einheit zu testen.
B 6овић
Bitte komm und sieh dir meinen Code an;) Beim Üben von TDD ist es immer möglich, diese Art von Fehler sehr schnell zu zeigen.
Mik378
@ Mik378 das stimmt nachweislich nicht. Der Punkt ist, wenn Sie Zahnspangen verwenden, müssen Sie sich nicht einmal darum kümmern.
GoatInTheMachine