Design
|
- macht top down Design
und bottom up Implementierung
- analysiert erst das gesamte Problem und zerlegt es in
einfache, unabhängige Teilprobleme
- schreibt Funktionen für die primitiven Operationen
- setzt hieraus die Gesamtlösung zusammen
|
| |
Redundanz
|
schreibt Code mit sehr geringer Redundanz
|
|
- wenn mehr als drei Zeilen zwei mal auftauchen, wird
das Programmieren unterbrochen und nachgedacht
- (fast) gleiche Zeilen werden zu einer Routine zusammengefasst
- oder: größere Reorganisation
überarbeitung der Modularisierung
|
| |
|
Anzahl späterer Modifikationen wird reduziert
- bei Fehlerelimination
- bei Erweiterung der Funktionalität
|
| |
|
wenige allgemeine Routinen werden besser und häufiger
getestet als viele selten aufgerufene Spezialroutinen
|
| |
Testen
|
schreibt parallel zum Programm ein Testsystem
für jede neue Routine gleichzeitig ein neuer Testfall
|
| |
|
schmeißt keine Testfälle weg
|
| |
Korrektheit
|
schreibt Code, der sich selbst überprüft
|
|
- wertet Vor- und Nachbedingunen aus
- bricht das Programm mit einer lesbaren Fehlermeldung ab
|
| |
|
Benutzer sind ab und zu verärgert über interne Fehlermeldungen
und Programmabbruch, können aber in vielen Fällen durch Änderung der
Eingaben den Fehler umgehen
|
| |
|
Benutzer bekommen ganz selten falsche Resultate
|
| |
Wartbarkeit
|
schreibt Programme, die er vergessen kann
|
| |
|
wenn niemand anderes an einem Programm arbeiten kann, bleiben
sie viel zu lange an ihren Programmen hängen, obwohl sie gerne etwas
neues machen möchten
|
| |
Lesbarkeit
|
beachtet, dass kompakte Programme und kompakte
Programmiersprachen ausführlichen Kommentar erfordern
|
| |
Können
|
- kann kurze und einfache Programme zur Lösung
eines Problems schreiben
- kann die Funktionalität erweitern durch Erweiterung
der Datenstrukturen
|
| |