Verwenden Sie Behauptungen?

Question

Das ist nicht wirklich eine Frage, also mache ich es CW.

Die

assert 

Schlüsselwort ist groß!

Es sollte machen, fühlen Sie sich selbstbewusster mit dem Code, den Sie geschrieben haben, aber bis heute, als ich eine kleine Testklasse (< 20 Zeilen) erstellte, merke ich, dass ich sie nie benutze, seit sie eingeführt wurde.

Heck! Ich benutze kaum Logger, was in der Tat sehr nützlich ist, aber bis heute wurde mir klar, dass ich keine Behauptungen verwende.

Verwenden Sie Assertionen? Wenn nein, was ist der Grund?

Answer 1

Nein, benutze sie nie. Weiß nicht, warum, nur nie zur Gewohnheit geworden.

Answer 2

Ich neige dazu, sie nicht zu verwenden, obwohl ich nicht sicher bin, warum auch nicht.

Wenn Sie Komponententests durchführen, z. B. mit nUnit, würden Sie diese natürlich ständig verwenden, um Ihre Testergebnisse zu überprüfen.

Answer 3

Mir wurde beigebracht, viele Behauptungen in den 90er Jahren zu verwenden, und sie machten großen Sinn. Es ist eine gute defensive Codierung.

Ich glaube jedoch, dass dies nun durch Komponententests ersetzt wurde, die den Code zum Ausführen zwingen und sagen, wo er kaputt ist. Debuggen erfordert, dass jemand tatsächlich Debug-Code ausführt und sich die UI oder Protokolle anschaut. Komponententests können dies automatisieren.

Answer 4

Ich benutze sie die ganze Zeit. Sie sind eine gute Möglichkeit, die "Crash Early" -Philosophie zu üben, besser zu lösen, warum eine Assertion fehlgeschlagen ist, als mit schlechter/korrupter Ausgabe umgehen zu müssen.

Das Problem ist, dass Sie es zur Gewohnheit machen müssen. Ich sehe selten einen Mittelweg darin, die Leute sind entweder nicht daran gewöhnt und benutzen sie fast nie, oder die Leute benutzen sie und sie sind rigoros im Code verstreut. Du musst nur in die Denkweise kommen, um zu merken "Oh hey, ich bin implizit etwas hier anzunehmen, lass es mich ausdrücklich bestätigen 'bestätigen (ÜBERNAHME)'"

Answer 5

Ich benutze sie nicht. Unit-Tests sollten ausreichen, um Ihren Code zu testen. Da sie standardmäßig deaktiviert sind, werden sie normalerweise sowieso vollständig ignoriert. Dann neigen sie dazu, Ihren Code mit nutzlosen Behauptungen zu überladen, die besser als Kommentare ausgedrückt werden könnten.

Wenn Sie das wirklich brauchen, aber haben einige Bibliotheken Behauptung statische Methoden, die Sie, dass rufen können nicht übersprungen werden - das ist auch viel besser lesbar, weil das assert Schlüsselwort ungewöhnlich ist und sofort verursacht eine „wtf "Moment, aber die Assert.x-Methoden sind nur Methoden, die durchgespürt werden können. Das Spring-Framework verwendet insbesondere eine Assertion-Bibliothek.

Answer 6

Kurze Antwort - Ja.

Lange Antwort - Nicht immer, aber ziemlich oft. Ich verwende normalerweise Behauptungen für Fehler, von denen ich weiß, dass ich nichts dagegen tun kann (während das Programm läuft), und eine Protokollierung ist nicht wirklich erforderlich. Zum Beispiel - wenn ich prüfen muss, ob ein bestimmter Wert außerhalb der Grenzen liegt oder ob ein Zeiger NULL ist, obwohl er einen Wert haben sollte.

Für andere Sachen wie "Parsing Dateien" und "Datei konnte nicht gefunden werden", ich normalerweise Ausnahmen auslösen.Auf diese Weise kann ich den Fehler protokollieren und stattdessen eine fehlersichere Datei/Methode verwenden.

Und ich stimme ganz mit mit Falaina, sollten Sie wirklich machen es zu einem Punkt zu bemerken - „HEY Ich mache einige Annahmen hier“

Answer 7

Ich neige dazu, auf Fehlerbedingungen zu überprüfen und Ausnahmen, anstatt zu werfen. Der Grund ist, dass ich möchte, dass diese Bedingungen immer geprüft werden, sogar in der Produktion, und Ausnahmen sorgen für eine leichtere Handhabung der fehlgeschlagenen Bedingung anstelle von Behauptungen.

Answer 8

Ich verwende Behauptungen, um sicherzustellen, dass ich keine Fehler in meinen Code einfüge. Wenn ich weiß, dass ein Wert in einer Map enthalten sein sollte, setze ich dies (mit dem assert-Schlüsselwort) durch. Wenn ich weiß, dass ein Parameter niemals Null sein sollte, behaupte ich dafür. Wenn ich weiß, dass der Parameter null sein kann, werde ich es überprüfen und die entsprechende Ausnahme auslösen.

Ich las es bei Code Complete oder Effective Java - Behauptungen sollten verwendet werden, um Programmierfehler zu erkennen - Ausnahmen sollten verwendet werden, um außergewöhnliche aber mögliche Situationen zu behandeln. Sie müssen nicht bei jeder Methode in Ihrem Code auf Null prüfen, wenn Sie wissen, dass der Wert nicht null ist (wie durch einen Vertrag definiert), aber es tut nicht weh, wenn ein Wert nicht null ist. Assertionen werden nur aktiviert, wenn Sie den Parameter -ea für die VM angeben. Sie sollten die Leistung Ihrer Anwendung nicht beeinträchtigen, wenn sie deaktiviert ist.

Sie sollten auch mehr Protokollierung verwenden :-). Erfahren Sie, wann Sie Trace, Debug und Info verwenden und stellen Sie sicher, dass Sie alles protokollieren, was Ihre Anwendung tut. Es erleichtert das Leben, wenn Sie herausfinden müssen, warum etwas in einer Produktionsumgebung nicht funktioniert.

Answer 9

Nein, ich benutze sie nicht.

Ich wurde unterrichtet, dass behauptet, sollte nicht in 'Produktion' Code verwendet werden, und bevor ich etwas zu verwenden, die ich sowieso entfernen muss - je nachdem, was ich gelernt habe - halte ich mit Ausnahme, Bedingungen zu validieren.

Answer 10

Ich benutzte sie nie, aber ich hatte eine schreckliche Zeit, mein letztes Programm zu debuggen, und zu einem Zeitpunkt protokollierte ich, wenn Variablen null waren oder nicht die Werte enthielten, die ich erwarten würde. Sobald ich alles in Ordnung gebracht hatte, behauptete ich alles, was mein Programm brauchte, um erfolgreich zu laufen.

Answer 11

Das Java-Assert-Schlüsselwort ist ziemlich halb-assed (muss das Programm mit der Befehlszeilenoption -ea ausführen), so dass ich mich auf Ausnahmen verlassen muss, statt zu bestätigen.

Answer 12

Die einzige echte Verwendung für Assertionen nach dem Testen von Einheiten wurde eingeführt, um die Invariante einer Methode anderen Programmierern mitzuteilen. Und es ist viel besser, dies im tatsächlichen Code als in Kommentaren zu tun, die sie sowieso ignorieren werden. Es ist schwer, eine Behauptung zu ignorieren!

Answer 13

Nein. Aber kann nicht warten. Früher habe ich alles mit Junit getestet, aber das war Schule, kleine Projekte haben keinen Druck. Ich bin im wirklichen Leben jetzt, ich sollte diesen Code gestern beenden ....

Answer 14

Wenn Sie möchten behauptet, Sie werden Verträge zu lieben. Sie sind im Grunde die Idee von Behauptungen, die sich auf mehr Situationen erstrecken.

Answer 15

Ja! Immer! Das Schlüsselwort ist mein bester Freund in jeder Sprache!

Es gibt keinen wirklichen Grund, keine Behauptungen zu verwenden, sie stellen sicher, dass die Grundannahmen, die ich an Eingabewerten und Zuständen anstelle, eingehalten werden.

Wenn eine Assert fehlschlägt, bedeutet dies, dass ich meine Annahmen neu bewerten und den Code aktualisieren muss, um neue exotische Eingaben zu verarbeiten, an die ich beim Schreiben der aktuellen Revision nicht gedacht habe. Was ist daran nicht zu mögen?

Wie bei der Programmierung üblich, handelt es sich um ein Werkzeug, das nur bei richtiger Verwendung leistungsstark ist.

Answer 16

Ja, ich verwende behauptet die ganze Zeit, im Grunde, wenn ich eine Annahme mache, dass:

1. kann mit einem recht einfachen Prädikat überprüft werden.
2. Dies ist offensichtlich nicht wahr, einfach aus dem Code in der Nähe zu lesen.

jedoch für behauptet, dass wahrscheinlich eine vernachlässigbare Auswirkungen auf die Leistung haben, verwende ich die enforce Funktion in der Programmiersprache D-Standardbibliothek statt assert. Dies funktioniert im Prinzip genauso wie assert, nur dass es im Freigabemodus bleibt. Für teurere Assertionen verwende ich assert, das aus den Builds im Release-Modus entfernt wird.