DseWiki: IstAssertSinnvoll/UndWieWeitSollEsGetriebenWerden

Veränderung (letzte Änderung) (keine anderen Diffs, Normalansicht)

Verändert: 7c7,15

Mir gefällt im übrigen Helmuts rein spekulative Behauptung, die Vorbedingung würde in seiner rein spekulativen Sammlung von Stringfunktionen hundertemale vorkommen, nicht. Die Bedingung würde man nur dort aufführen, wo sie eben wirklich Bedingung ist (sprich, wo das Argument konkret irgendwie dereferenziert wird), also z. B. nicht dort, wo in einer Funktion lediglich sich anderer Hilfsfunktionen bedient wird, oder z. B. auch dort nicht, wo NULL gültiger Eingabewert ist (kann man doch manchmal gut so machen). -- VolkerGlave

:Die NULL als gültiger Eingabewert ist eine seltene, schlechte (weil dokumentierungsbedürftige) Ausnahme. Die spekulative Sammlung findet sich unter HelmutLeitner/StringFunktionen und 70-100 reine Stringfunktionen ist vermutlich niedrig gegriffen, ich habe sie noch nicht abgezählt. -- hl

::Das erste akzeptiere ich in dieser Absolutheit nicht. Z. B. bei einer Funktion "void kopiere(char* nach, const char* von)" halte ich es für absolut legitim und für nicht notwendigerweise extra dokumentierungsbedürftig, dass bei einem aktualen Wert NULL des Arguments von halt nichts in das Argument nach kopiert wird. Als Funktonsbeschreibung kann man sagen "Kopiert den String von in den String nach (der über ausreichend Platz verfügen muss)". kopiere(str, "123") kopiert "123" nach str, kopiere(str, "") kopiert einen Leerstring nach str, kopiere(str, NULL) kopiert nichts nach str, läßt str also unverändert, wunderbar, warum nicht. -- vgl

:Meine negative Einschätzung von NullAlsInputParameter ist nicht als absolute Wertung zu sehen, sondern als individuelle Festlegung im Rahmen meines persönlichen Coding-Standards. Für mich ist bei solchen Stilfragen immer entscheidend (und das trifft auch IstAssertSinnvoll): kann man eine universelle Regel für die Anwendung des Stilelements entwickeln. Wenn nein, dann ist das Stilelement IMO im Rahmen einer technischen Betrachtungsweise nicht brauchbar, weil eine Implementierung des Interfaces dann kein eindeutiges Ergebnis besitzt. Man kann aber IMO durch geeignete Maßnahmen im Interface-Design Eindeutigkeit herstellen und das Problem entschärfen. Dass die obige Funktion "kopiere" keine gute Lösung ist, lässt die Implementierung von "strcpy" vermuten. -- hl

::Die vertretene Ansicht, "kopiere" sei, wie die Implementierung von "strcpy" vermuten lasse, keine gute Lösung, basiert wie mir scheint auf der Annahme, "kopiere" würde "strcpy" nachahmen wollen. Nur wurde das nirgends behauptet oder angedeutet. Wobei, wenn wir nun schon dabei sind: Erfüllt ein "strcpy", das sich bzgl. der NULL-Eigenschaft des zweiten Arguments so wie "kopiere" verhält, denn den CeeStandard nicht? -- vgl

assert() ist ein Ansatz für DesignByContract in C. Wenn eine Funktion als wesentlicher Baustein eines C-Programms Nach- oder Vorbedingungen hat, dann sind diese durch ein assert() dokumentierbar. Der zusätzliche Vorteil, dass zumindest in der Debug-Version (das ist die Version, in der auch die Debug-Informationen enthalten sind, die also evtl. um vieles größer ist als die Release-Version) auch geprüft wird, ob diese als sicher gemachten Annahmen auch immer erfüllt sind, kann helfen, stabilere Bausteine zu erzeugen. Eine Bedingung ist entweder für die Korrektheit einer Funktion als Baustein erforderlich (dann ist sie keine Trivialität) oder nicht. -- KurtWatzka

: Nehmen wir den Fall einer Sammlung von Stringfunktionen, wie sie jeder Praktiker benötigt. Sie mag aus 70-100 kleinen Einzelfunktionen bestehen, die typischerweise 1-3 Stringparameter übernehmen. Die Vorbedingung "assert(string!=NULL)" würde hundertemale vorkommen, ist trivial und trägt nichts zur Dokumentation bei. In diesem Sinne meinte ich das "trivial". P.S. Die obige Bedinung ist für die Funktion jeweils notwendig, also in deinem Sinne nicht trivial, du hast sie aber in ZeigerAufAusreichendPlatzAlsCeeIdiom nicht formuliert. -- HelmutLeitner

"Trägt nichts zur Dokumentation bei" ist, jedenfalls für mich, der entscheidende Halbsatz. Ich sehe es auch nicht als inkonsequent an, Selbstverständliches nicht mit assert zu dokumentieren. Die Frage ist natürlich, wo das Selbstverständliche aufhört und wo das Bemerkenswerte beginnt. Das ist aber eine Frage, die sich bei der Dokumentation von Software immer stellt. Das wesentliche Kriterium ist dabei meiner Meinung nach, an welchen Leserkreis sich die Dokumentation richtet. Meine Hoffnung ist, dass sich ein in C geschriebener Quelltext an jemanden richtet, der die Programmiersprache C mehr als nur oberflächlich kennt. -- kw

Die NULL als gültiger Eingabewert ist eine seltene, schlechte (weil dokumentierungsbedürftige) Ausnahme. Die spekulative Sammlung findet sich unter HelmutLeitner/StringFunktionen und 70-100 reine Stringfunktionen ist vermutlich niedrig gegriffen, ich habe sie noch nicht abgezählt. -- hl

: Das erste akzeptiere ich in dieser Absolutheit nicht. Z. B. bei einer Funktion "void kopiere(char* nach, const char* von)" halte ich es für absolut legitim und für nicht notwendigerweise extra dokumentierungsbedürftig, dass bei einem aktualen Wert NULL des Arguments von halt nichts in das Argument nach kopiert wird. Als Funktonsbeschreibung kann man sagen "Kopiert den String von in den String nach (der über ausreichend Platz verfügen muss)". kopiere(str, "123") kopiert "123" nach str, kopiere(str, "") kopiert einen Leerstring nach str, kopiere(str, NULL) kopiert nichts nach str, läßt str also unverändert, wunderbar, warum nicht. -- vgl

Meine negative Einschätzung von NullAlsInputParameter ist nicht als absolute Wertung zu sehen, sondern als individuelle Festlegung im Rahmen meines persönlichen Coding-Standards. Für mich ist bei solchen Stilfragen immer entscheidend (und das trifft auch IstAssertSinnvoll): kann man eine universelle Regel für die Anwendung des Stilelements entwickeln. Wenn nein, dann ist das Stilelement IMO im Rahmen einer technischen Betrachtungsweise nicht brauchbar, weil eine Implementierung des Interfaces dann kein eindeutiges Ergebnis besitzt. Man kann aber IMO durch geeignete Maßnahmen im Interface-Design Eindeutigkeit herstellen und das Problem entschärfen. Dass die obige Funktion "kopiere" keine gute Lösung ist, lässt die Implementierung von "strcpy" vermuten. -- hl

: Die vertretene Ansicht, "kopiere" sei, wie die Implementierung von "strcpy" vermuten lasse, keine gute Lösung, basiert wie mir scheint auf der Annahme, "kopiere" würde "strcpy" nachahmen wollen. Nur wurde das nirgends behauptet oder angedeutet. Wobei, wenn wir nun schon dabei sind: Erfüllt ein "strcpy", das sich bzgl. der NULL-Eigenschaft des zweiten Arguments so wie "kopiere" verhält, denn den CeeStandard nicht? -- vgl