Meiner Meinung nach sollte auch kein Code nur auskommentiert werden. Allerdings, die Methode von rasc ist sicherlich OK, wenn der Code dann auch wirklich gelöscht wird. Auch das Kommentieren von Änderungen haben im Code eigentlich auch nichts zu suchen (das normale Kommentieren und die Funktionsdefinitionen jedoch sehr wohl).
Allerdings, wenn ich im Code meines Kollegen etwas ändere, kommentiere ich das in der Regel relativ ausführlich im Code, damit er schnell weiß, woher und warum der Code eingefügt wurde.
Neben der Änderungsdokumentation im cvs ist es meiner Erfahrung nach sehr sinnvoll, ebenfalls eine Revision-History im File-Header zu führen (Datum, Name, Änderungsnummer, Kurzbeschreibung) da der Weg über cvs oft recht umständlich ist (vor allem bei Projekten mit mehr als 1000 Files).
Vor allem denke ich aber, daß der Grund warum Software nach einiger Zeit unleserlich wird meißt daran liegt, daß zu viele Entwickler am gleichen Code (oder noch schlimmer fremden Code) rumwursteln, ohne irgendwelche Regeln zu beachten. Dazu kommt, daß nur der erste Entwickler alle Zusammenhänge seiner Software kennt. Alle Nachfolgenden verstehen meist nicht alle Kniffe des Vorgängers (10 Programmierer lösen das selbe Problem auf 10 verschieden weisen ..) und schon steigt die Gefahr von Verschlimmbesserungen.
Dagegen helfen nur strenge Coding- und Design-Regel, sowie ein starker Technical-Lead. Kostet natürlich Zeit (und Geld) funktioniert aber recht gut. Ohne jede Regeln kann zwar in kürzester Zeit Beachtliches geschaffen werden, nur die Wartung gerät meistens zur Katastrophe .
Ich bin ja noch nicht sehr lange hier aktiv, aber ich vermute, daß es bei Neutrino ähnlich war. Sprich, am Anfang war noch alles gut strukturiert und mit der Zeit (nachdem die anfänglichen Entwickler sich zurückgezogen haben) gingen die Probleme los.....
Bitte versteht das nicht als Kritik, so ist wohl der Lauf der Dinge (nicht nur bei OpenSorce sondern auch bei Firmen
)
