Automatisch Laufen einer Person

[R.D.]

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.

...

Ja, genau das ist für mich auch normal. Was ich aber "gelernt habe" ist sowas:

Code:

/**
 * Die Klasse In dient zum Einlesen von Daten �ber Klassenmethoden bis Eingabe
 * und Ausgabe (input output kurz IO) im 2. Semester behandelt werden.
 * Dann werden die M�ngel der In Klasse besprochen und diese verbessert.<br>
 * <br>
 * Folgende globale Klassenvariable ist implementiert: private static BufferedReader tastatur <br>
 * <br>
 * Die Klassenmethoden erm�glichen das Einlesen der einfachen Datentypen 
 * und einer Zeichenkette (String) von Konsole, Diee Methoden sind nach folgendem Schema benannt:
 * readDatentyp.<br>
 * <br>
 * Der Eingabestrom wird nicht geschlossen, damit mehrere Methoden gleichzeitig eingesetzt werden k�nnen. 
 * Deshalb auch die globale Klassenvariablen! <br>
 * 
 * @author Gabriele Schmidt
 * @version 1.2
 * 
 */

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.

...

Ok, da hast du natürlich recht. Arg aber auch
Ich muss zugeben das ich bei den Code hier:

Code (java):

for(int i = 0; i < enemy.size(); i++) {
        if(waveStart.get(i) < distance && waveStop.get(i) > distance) {
          for(int j = 0; j < enemy.get(i).size(); j++) {
            if(enemy.get(i).get(j).isAlive() && !enemy.get(i).get(j).isOutOfWindow()) {
              g2d.drawImage(enemy.get(i).get(j).getImage(), enemy.get(i).get(j).getX(), enemy.get(i).get(j).getY(), this);
            }
          }
        }
      }

Tatsächlich Kommentare habe, auch wenn es eigentlich klar ist was passiert (nur halt nicht für meinen Partner).

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.

...

Ich denke, du hast schon Recht. Ich bin wahrscheinlich noch viel zu unerfahren und habe noch gar nicht so kompliziertes Zeug gebaut (Außer beim Maker, da habe ich auch etwas komplere Sachen nicht kommentiert, einfach weil ich damit Erfahrung habe.

[Kyuu]

Kommentare sollten - ausgehend von einer sauberen Programmierung - nicht beschreiben was der Code macht, sondern wieso er da ist. Was der Code macht sollte aus dem Namen der Routine hervorgehen. Der folgende Kommentar ist zum Beispiel vollkommen redundant:

Code (C++):

 
/* Tut dies und das. */
void tueDiesUndDas() {
    /* ... */
}
 

Während dieser durchaus gerechtfertigt ist:

Code (C++):

 
void tueDiesUndDas() {
    /* ... */
    A* a = new A();
    /* da ältere MSVC-Versionen bei fehlgeschlagener Speicherreservierung
        statt std::bad_alloc zu werfen einen Nullzeiger zurückgeben */
    if (!a) {
        throw std::bad_alloc();
    }
    /* ... */
}
 

Oft wird natürlich auch die Kommentierung des Rückgabewertes, sowie der Parameter einer Routine benötigt, besonders bei komplexeren Datenstrukturen in Verbindung mit fehlender automatischer Speicherbereinigung (C/C++), oder der Vermerk der Vor- und Nachbedingungen, sowie der Invarianten (Design By Contract). In diesen Fällen sind auch seitenlange Kommentare völlig gerechtfertigt.

Die Aussage, dass es unsinnig ist eine Zeile Code mit 4 Zeilen Kommentar zu versehen ist selbst unsinnig. Vom Code- zu Kommentarzeilen-Verhältnis kann man nicht auf den Sinn, oder Unsinn eines Kommentars schließen.

Das Kommentar-Beispiel von makenshi dient eher der API-Dokumentation für Tools wie Javadoc, oder bei C/C++ Doxygen, was natürlich auch seinen Sinn hat, aber als Beispiel dafür, wie professioneller Code kommentiert wird, würde ich es nicht nehmen. Ein allgemeingültiges Beispiel kann man sowieso schlecht finden, da es immer auf die Situation ankommt.

[Rpgmaker11]

Ich versteh grade garnixmehr sehr kompliziert ...