Dokumentation: Unterschied zwischen den Versionen
Aus Das Sopra Wiki
Jeremi (Diskussion | Beiträge) |
Sabine (Diskussion | Beiträge) |
||
| Zeile 130: | Zeile 130: | ||
Kommentieren ist schön und gut, aber wann genau soll nun kommentiert werden? Es gibt mehrere Ansätze, Kommentare zu verfassen, die auch von dem jeweiligen Programmierstil abhängen. | Kommentieren ist schön und gut, aber wann genau soll nun kommentiert werden? Es gibt mehrere Ansätze, Kommentare zu verfassen, die auch von dem jeweiligen Programmierstil abhängen. | ||
Bei einem geplanten Vorgehen überlegt man sich im Voraus, was der Code genau leisten soll. Dann spezifiziert man die Parameter und die Rückgabe und verfasst noch vor dem Implementieren einen Kommentar der beschreibt, was der Code leisten wird. Vorteil dieses Ansatzes ist, dass auf diese Weise Funktionen und Klassen markiert werden können, die man (oder ein anderer Entwickler) erst später implementieren wird. Solche Codestellen sollten unbedingt mit einem [[Dokumentation#Aufgabenliste-Kommentare| | Bei einem geplanten Vorgehen überlegt man sich im Voraus, was der Code genau leisten soll. Dann spezifiziert man die Parameter und die Rückgabe und verfasst noch vor dem Implementieren einen Kommentar der beschreibt, was der Code leisten wird. Vorteil dieses Ansatzes ist, dass auf diese Weise Funktionen und Klassen markiert werden können, die man (oder ein anderer Entwickler) erst später implementieren wird. Solche Codestellen sollten unbedingt mit einem [[Dokumentation#Aufgabenliste-Kommentare|Aufgabenliste-Kommentar]] markiert werden. | ||
Geht man etwas ungeplanter vor, so kann es passieren, dass man eine Funktion implementiert, diese aber kurze Zeit später erweitert, überarbeitet oder gar durch eine neue ersetzt. Jetzt jederzeit Kommentare zu schreiben, die man nur wenige Minuten später wieder wegschmeißt ist unnötiger Aufwand. Aus diesem Grund schiebt man das Kommentieren und somit das Dokumentieren der Funktion vor sich her. Dennoch sollte die finale Version der Funktion letztendlich kommentiert sein. | Geht man etwas ungeplanter vor, so kann es passieren, dass man eine Funktion implementiert, diese aber kurze Zeit später erweitert, überarbeitet oder gar durch eine neue ersetzt. Jetzt jederzeit Kommentare zu schreiben, die man nur wenige Minuten später wieder wegschmeißt ist unnötiger Aufwand. Aus diesem Grund schiebt man das Kommentieren und somit das Dokumentieren der Funktion vor sich her. Dennoch sollte die finale Version der Funktion letztendlich kommentiert sein. | ||
