m.fuchs hat geschrieben:Ich wiederhole mich solange bis es angekommen ist: Unittests, Unittests, Unittests! Und zwar mit allen Checks.
Da kommt es dann auf die Zeitverzögerungen der Prüfungen nicht an und sorgt für einen funktionierenden Code.
All diese Probleme die hier geschildert werden, habe nichts mit dem nicht-0-basiertem Index zu tun. Dass ich irgendwo hinschreibe, wo ich nicht hinschreiben soll kann mir auch so passieren. Und eben darum sichert man das ab.
Dagegen sage ich ja nichts, aber du hast meine prämisse falsch verstanden. Man muss davon ausgehen das bei einem größeren Projekt irgendwann es zwangsläufig passiert das jemand mit for i:=0 to Length(arr)-1 durch einen array iteriert. Das viele eventuell drüber iterieren weil sie das -1 weglassen gibt es zwar auch, aber danach lässt sich sehr einfach finden. Dafür muss man den Code nicht verstanden haben, jedem Programmierer egal ob java, Pascal oder C würde bei der zeile for i:=0 to Length(arr) do die arlamglocken läuten, während for i:=0 to Length(arr)-1 auf den ersten blick korrekt aussieht und man muss überall die datentypen überprüfen was deutlich mehr aufwand ist. Und Testsuites sind niemals vollständig, selbst die seit jahrzehnten gepflegte CoreUtils Test suite coverd nur 80% des Codes. Das muss nur eine kleine For schleife sein die von den Tests nicht abgedeckt wird und irgendwann knallt es
Wenn man alle Arrays mit 0 beginnen lässt schließt man eine komplette semantische Fehlerklasse aus. Man könnte meinetwegen auch alle arrays mit 1 oder -45 anfangen lassen, dann ist es aber nicht mit den Dynamischen Arrays konsistent
