Zitat Zitat
Ich glaube hier liegt ein missverständnis vor. Ich denke ich sehe viel Kommentar anders als du. Vom Studium kenne ich, das für ganz einfache Sachen echt einer 2 Kommentare für eine Codezeile gemacht hat, das ist imho
zuviel.
Das ist eine so nicht haltbare Pauschalaussage. Je nachdem was in dieser einen Zeile Code passiert kann es durchaus sinnvoll sein viel Kommentar dahinter zu hängen. Besonders in Skripten in denen Erklärungen stehen ist es besser eine Zeile ausführlich zu erklären als sie der Interpretationsgabe des Leser zu überlesen. Man kann immerhin im voraus nie wissen welchen Stand dieser hat.

Zitat Zitat
Klar mach ich auch über fast jede Methode ein Kommentar, aber maximal mit einer Zeile (sofern es nicht näher erklärt werden muss, wie gesagt bei Teamarbeit ist das was anderes). Setter und Getter würde ich nur einmal kommentieren und nicht jedesmal neu.
Setter und Getter sind ein absoluter Sonderfall. getTime() im Bezug auf ein Dateobjekt bspw. ist da ausnahmsweise Beschreibung genug. Eine ordentliche Methodenkommentierung sieht immer noch so aus:
Code:
/**
* Generiert ein Objekt.
* @param parameter Daten die für die Erzeugung des Objekts
*                  erforderlich sind.
* @return Das generierte Objekt
*/
public Object generateObject(Datentyp parameter){
// ...
}
Das ist jetzt am Beispiel einer Javadoc zusammengebaut. Bei diesem Methodenkopf kann erstmal jeder schon bei reiner Benutzung sehen wie sie zu benutzen ist, was sie erwartet und was man zurückbekommt.
Eine Zeile für eine Methode ist also viel zu wenig. Professioneller Quellcode sieht imo anders aus. Es heisst nicht umsonst das richtige "Programmierer" kommentieren. Und zwar anständig.

Zitat Zitat
Ich sehe viel Kommentar halt so, das man im Detail beschreibt was eine Methode macht. Ich meine, es reicht wenn man das Stichpunktartig macht, bzw haben wir das bei der Teamarbeit auch so beschlossen (und ich bin noch lange nicht so gut in Java wie mein Teampartner).
Nein, viele Kommentare müssen nicht zwangsläufig sein das man im Detail beschreibt was dort abläuft. Das ist bei Erklärungsskripten wie gesagt sinnvoll, in einer "richtigen" Anwendung eher nicht. Dort sind Stichpunkte ok, jedoch sollten dort auch allerlei Informationen untergebracht werden die nötig sind um den Context des Codes zu verstehen. Warum wurde Methode xyz aufgerufen? Warum wende ich den regulären Ausdruck dort an? Das ist nicht immer aus den Reihen Codezeilen ersichtlich.

Ich denk einfach das gute Programmierung grundsätzlich was damit zutun hat das man auch diesen Part richtig angeht. Und Aussagen die in Richtung "das ist nicht immer so wichtig", sind mit äußerst Vorsicht zu begutachten. Sie zeugen meist von falschem Verständnis was die Kommentierung angeht.