DseWiki: IstAssertSinnvoll/OderIstEsGeschmacksache

Ja, assert() ist sinnvoll, und ich sehe nicht, was es da lange herumzudiskutieren gibt. Ich habe als C/C++-Entwickler so die Möglichkeit, Bedingungen zu formulieren, von denen ich zu wissen meine, dass sie unter allen Umständen zutreffen. Von Zeit zu Zeit zeigt sich dann eben, dass ich mich geirrt habe (such is life), und mir springt das Ding ins Gesicht. Sicher, nur im Debug-Modus. So what? Eben dafür ist es ja da. Klar, ich kann mich auch bei der Formulierung der Bedingungen selbst täuschen. Und, ja, die Dinger nehmen etwas Laufzeit in Anspruch, vielleicht sogar zuviel. Shit happens. Na und, dann werden die Bedingungen eben korrigiert oder fliegen raus. Wo ist das Problem? -- VolkerGlave

Das ist Geschmackssache, viele Entwickler leben auch gut ohne assert. -- HelmutLeitner

Oder es ist doch keine Geschmackssache und Entwickler, die assert - so, wie es gedacht ist - einsetzen, kommen (modulo anderer Einflüsse, um die es hier nicht geht) grundsätzlich zu besseren Ergebnissen als Entwickler, die es nicht tun. Trotzdem stimmt es natürlich, dass viele Entwickler gut ohne assert leben können, so wie auch viele Autofahrer gut ohne Gurt leben können. -- vgl

Es gibt ein paar wichtige Unterschiede zwischen Assertions und Autogurten: in den allermeisten Anwendungen sind Assertions nicht in der Lage, Leben zu retten - daher bekommt die Kosten/Nutzen-Rechnung eine viel höhere Bedeutung. Zudem gibt es zu Autogurten kaum sinnvolle Alternativen - zu Assertions gibt es die wohl schon, mit ähnlichem Effekt auf die Qualität der Software.

Und was sind die Alternativen? Mir fallen da zunächst mal Sprach-Features wie in Eiffel ein. Aber die kann man dort auch ein und ausschalten (Debug / Release-Mode). Immer alle Bedingungen per Programmcode zu prüfen und gegebenenfalls eine Exception zu werfen (wie z.B. in Java), bläht das Programm selbst stark auf (v.a. in Punkto Laufzeit). Also was gibt es sonst noch? --umw

Nach meiner Erfahrung kann z.B. TestgetriebeneEntwicklung zu einer solch umfassenden Suite von Tests führen, dass sich Assertions nur noch in seltenen Fällen wirklich auszahlen - z.B. an Schnittstellen zu Clientcode, der nicht unter der Kontrolle des eigenen Teams steht. -- IljaPreuß

: Assertions und TestgetriebeneEntwicklung haben beide Ihre Vorteile. Bei Assertions schätze ich den Dokumentations und den Bequemlichkeitsaspekt (Assertion ist nicht in einem anderen File, sondern steht direkt bei der Methode). Ich finde die Idee, den Test mit einer Komponente gleich mitzuliefern ebenfalls interessant. Ich denke wenn die Assertions ihren Runtimecharakter verlieren und über Beweisverfahren statisch ausgewertet werden können, währe das der wirkliche Gewinn. Dann hat man eine feinergranulare Typisierung, gegen die wohl keiner etwas einzuwenden hätte.
: Bei der TestgetriebeneEntwicklung arbeitet man mit konkreten Beispielen und hat es so einfacher, den Test zu formulieren, es ist auch klar daß es sich bei den Tests nicht um einen Programmbestandteil handelt, so darf ein Test auch rechenintensiv und umfangreich sein. Darüberhinaus kann man natürlich gezielt die kniffligen Fälle testen, bei Assertions muß man ja warten, bis so ein Testfall zufällig zur Runtime vorkommt ... -- mj