::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 |
::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 |
::::Assertions und TestgetriebeneEntwicklung haben beide Ihre Voteile. 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. |
::::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. |