Wie kommentiert ihr eure Programme?

Guten Abend,

da ich noch ein relativ unerfahrener Programmierer bin (wenn ich mich so nennen darf...) und bisher nur mit gleich erfahrenen Programmierer an einem Projekt gesessen habe die davon auch keine Ahnung hatten, wollte ich mal hören, wie ein Profi seine Programme kommentiert. Damit meine ich jedes Kommentar das man in einer Datei findet.

Ich sehe immer Kommentare über Methoden oder Eigenschaften einer Klasse. Welchen Aufbau und Inhalt sollten die Kommentare haben (allgemein bzw. persönlich betrachtet).

Ich danke im voraus für eure Antwort die mir und sicher auch anderen jungen Entwicklern helfen werden.

lg

Kevin

http://www.kuro5hin.org/story/2004/2/15/71552/7795  :-)

Original von Kevni

wollte ich mal hören, wie ein Profi seine Programme kommentiert. Damit meine ich jedes Kommentar das man in einer Datei findet.

Ich sehe immer Kommentare über Methoden oder Eigenschaften einer Klasse. Welchen Aufbau und Inhalt sollten die Kommentare haben (allgemein bzw. persönlich betrachtet).

  Ich kommentiere die Schnittstellen so, dass klar wird, was eine Funktion oder Klasse macht. Niemals, wie sie es macht (es sei denn, das ist Hilfreich, um die Funktionsweise zu erklären). Wenn es hilfreich ist, kommen noch Vorbedingungen und Nachbedingungen und welche Randbedingungen im multithreading Umfeld zu beachten sind, dazu. Es muss klar sein, was es macht und was man eben auch nicht erwarten darf. Kommentare in der Implementierung, könnten ein Hinweis darauf sein, dass der Code unverständlich sein könnte und benutze ich nur sehr spärlich. robitzki.de/log.h und robitzki.de/log.cpp wären ein Beispiel wie ich arbeite.

mfg Torsten

http://stackoverflow.com/questions/184618?tab=votes&page=3#tab-top

Und nun ernsthaft:

Alle Klassen und Funktionen:

- Was tut sie? 1 - 5 Zeilen Erklärung

- Was muss rein? Parameter und kurze beschreibung derer, meist 1-Zeiler

- Was kommt raus? Beschreibung der Return-Werte

- Welche Fehler sind zu erwarten?

Inline:

Beschreiben von Code-Blöcken und was hier getan wird. Hilft beim drüberlesen von Code, um eine geeigente Stelle zu suchen.

Variablennamen sollten natürlich für sich sprechen, und man sollte auf "exotische" kurze Schreibweisen verzichten, um höhere Lesbarkeit herzustellen.

Nabend,

vielen Dank schonmal für die bisherigen Posts ;) 

Finde es sehr interessant aus meiner Sicht, da ich diese (eigentlich selbstverständliche) Fakten in meinen Kommentare auslasse. Ich bin extrem faul und habe bisher mit wenigen Kommentaren gearbeitet. Dies soll sich absofort natürlich ändern ;)

Wie wäre es denn wenn ihr noch ein paar Beispiele aus euren Programmen postet? ;)

Die Formatierung der Kommentare ist auch extrem unterschiedlich wie ich gemerkt habe.

Danke für weitere Posts ;)

lg

Kevin

Was Kommentare betrifft bin ich irgendwie anders eingestellt als die meisten...

Ich versuche immer Code so zu schreiben und zu formatieren, dass das Überfliegen und Verstehen der Methode schneller geht als das Lesen eines eventuellen Kommentares. Wenn ich mal Kommentare schreibe, dann nur zum einfacheren Verständnis des Codes. Was genau eine Methode macht und wozu sie gut ist, sollte sich durch den Methodennamen und dem Kontext ergeben. Ein Kommentar braucht man da nicht...

Eine Ausnahme sehe ich bei Blackbox-artigen öffentlichen Schnittstellen, wo ich gern mal lange Kommentare drüberklatsche. Besonders für diejenigen, die keine Erfahrung mit Ruby haben.

Achja: Ich bin ein großer Fan von der "komm mal rüber und erklär mir das"-Arbeitsweise und frag (und nerve) lieber andere Leute als zu Googlen oder die Doku zu lesen :D Und ich freu mich auch immer wenn ich jemand anderem etwas erklären darf. Vielleicht spielt das da auch mit rein.

Original von buhrmi

Ich versuche immer Code so zu schreiben und zu formatieren, dass das Überfliegen und Verstehen der Methode schneller geht als das Lesen eines eventuellen Kommentares. Wenn ich mal Kommentare schreibe, dann nur zum einfacheren Verständnis des Codes. Was genau eine Methode macht und wozu sie gut ist, sollte sich durch den Methodennamen und dem Kontext ergeben. Ein Kommentar braucht man da nicht...

Ich glaube da besteht mittlerweile Konsens, dass Code auch ohne Kommentare lesbare sein muss. Nichts ist nerviger, als ständig den Code mit den Kommentaren abzugleichen um dann festzustellen, dass jemand den Code, aber nicht den Kommentar geändert hat. Wenn ich im Code viele Kommentare sehe, gehen bei mir meistens die Alarmglocken an und bei dem schlechten Code, den ich bis jetzt so gesehen habe, waren meistens auch sehr viele Kommentare im Spiel, dafür überlange Funktionen schlechtes Design, schlecht gewählte Bezeichner.

Original von Kevni

Wie wäre es denn wenn ihr noch ein paar Beispiele aus euren Programmen postet? ;)

http://robitzki.de/registry.cpp // fast ohne Kommentare

http://robitzki.de/registry.h // fast nur Kommentare

mfg Torsten

http://pastebin.com/7vprr3Bz

[Vorneweg: Java inside. Sry.]

Original von buhrmi

Was Kommentare betrifft bin ich irgendwie anders eingestellt als die meisten...

Ich versuche immer Code so zu schreiben und zu formatieren, dass das Überfliegen und Verstehen der Methode schneller geht als das Lesen eines eventuellen Kommentares. Wenn ich mal Kommentare schreibe, dann nur zum einfacheren Verständnis des Codes. Was genau eine Methode macht und wozu sie gut ist, sollte sich durch den Methodennamen und dem Kontext ergeben. Ein Kommentar braucht man da nicht...

Eine Ausnahme sehe ich bei Blackbox-artigen öffentlichen Schnittstellen, wo ich gern mal lange Kommentare drüberklatsche. Besonders für diejenigen, die keine Erfahrung mit Ruby haben.

Ja, genauso. Die Beispiele von Todi42/Torsten entsprechen dem auch.

Inline-Kommentare (d.h. Implementierung) sind für mich nur folgenden Situationen wichtig: 

• Es wird etwas sehr Unübliches gemacht (etwa ein Fallthrough im Switch-Case, evtl. ein continue/break in einer Schleife, ignorierte Exceptions, u.ä.). In der Regel sind statische Code-Analyse-Programme auch in der Lage diese entsprechende Kommentierungen zu erkennen und diesen "schlechten" Code doch ohne Warnung zu erlauben. 
• Das unnatürliche Behandeln von Exceptions (Java), sei es des explizite Nichtbeachten oder das explizite Benandeln.
• Es gibt etwas extrem spezielles, feste Literale, spezielle Inline-Konfigurationen.
• Es ist wirklich so harte Materie (Algorithmus), dass eine Kommentierung als sinnvoll erscheint.

Bei Schnittstellenkommentierung (das primär wichtige) ist natürlich auch relevant wie das Gesamtsystem aussieht.* "Mein" Projekt (nicht in der BG-Szene) läuft auf Basis des Spring Frameworks - wenn man sich nun darauf einlässt und die Strukturen und Konventionen einhält, spart man sich nicht manchen Code, sondern auch Kommentar-Boilder-Code.

Ein weiterer Punkt ist die Fachlogik: Kommentare auf Entitäten halte ich zu mindestens bisher für überflüssig. Darüber hinaus ändert sich das in einem agileren Projekt eh dauernd - und bei ORM sollte man ja in der Lage sein, und sprechende Entitäten schreiben zu können. Spezielle Service-Aufgaben werden entweder kommentiert, oder wahlweise auf eine externe Dokumentation (Trac, Wiki) ausgelagert, falls es schon zu komplex für eine Inline-Doc sein sollte (bzw. jene nicht ausreicht).

Ich gehe auch hin, und kommentiere Teile der Fachlogik selbst in einem Service-Interface nicht mehr: Warum sollte ich List := getAccounts(), Account := getAccountByUsername(string) des Services/DAO noch irgendwie kommentieren? Aus der Schnittstelle gehen Variablentypen eindeutig hervor und die Datenbanktransaktion wird in diesem Falle (Service) auch per Annotation angegeben (JPA/Hibernate). Einzig allein die Fehlerbehandlung (Was passiert im Falle von username=null?) könnte man erwähnen; sowie was passiert, wenn etwa kein Benutzer gefunden wurde.*

Falls also etwa ein leerer Username überhaupt relevant wäre, ergibt die Rückgabe eben ein defensives NULL. Das gleiche gilt für den Fall, das kein passender existiert. Eine Exception zu werfen ist dagegen sehr offensiv und muss auf jeden Fall benannt werden - und behandelt.

Halb OT: Je nach Sprache, Framework und Vorlieben gibt es auch die Möglichkeit, im Code direkt bestimmte Prüfungen vorzunehmen. In C gibt es die banalen Asserts, in Java passende Äquivalente in diversen Bibliotheken. Für Schnittstellen (also Methoden, d.h. beim Aufruf der Methode selbst) beinhalten etwa die FindBugs-Annotationen eine Reihe von Extras, um Prüfungen zur Prüfzeit (nicht Ausführung!) zu minimieren (Supress Warnings) oder zu erweitern (Beispiel: findByUsername(@NotNull String username)). Der Vorteil von so einer Vorbedingungen ist, dass sie sogar mit Hilfe einer Code-Analyse (hier: FindBugs) wahlweise während der Entwicklung oder auf dem Build-Server verwendet werden kann.

* Auch das kann man minimieren, indem für das Projekt übliche Standardvorgehen aufstellt und einhält. Also beispielsweise grundsätzlich tolerante, und defensive Schnittstellen.. oder sehr offensive, die jeden Fehler bereits mit einer Exception quittieren.

Es kommt darauf an, für was man entwickelt. Ein JavaScript-Projekt entwickele und kommentiere ich natürlich ganz anders als das Java-Projekt. Oder gar PHP-Projekt. ;) (Stichwort: Variablentypen).

 Du entschuldigst dich für Java, das find ich gut ;)

Original von knalli

Ich gehe auch hin, und kommentiere Teile der Fachlogik selbst in einem Service-Interface nicht mehr: Warum sollte ich List := getAccounts(), Account := getAccountByUsername(string) des Services/DAO noch irgendwie kommentieren? Aus der Schnittstelle gehen Variablentypen eindeutig hervor und die Datenbanktransaktion wird in diesem Falle (Service) auch per Annotation angegeben (JPA/Hibernate). Einzig allein die Fehlerbehandlung (Was passiert im Falle von username=null?) könnte man erwähnen; sowie was passiert, wenn etwa kein Benutzer gefunden wurde.*

bei mir würde das so aussehen:

/**

* Gibt eine Liste von Accounts zurück, die zu dem Usernamen passen

* @param string username String mit dem Benutzernamen, nach dem gesucht werden soll.

* @Return LIST Es kommt eine Liste von Usernamen zurück, wenn keiner gefunden wurde, ein "NULL".

* @Exception: MissingParameterException übergebener username ist leer

*/

Die Maguma-Workbench hat das gleich beim Aufruf mit angezeigt, Netbeans ebenfalls. Ich bin mir fast sicher, das Eclipse sowas auch macht. Ich muss als gar nicht im Code nachgucken, was das Ding nun im Fehlerfall macht (was bei komplexen Methoden natürlich aufwendiger ist als in dem Falle).

Sicher, das war auch nicht der Punkt. Jedoch ist von deinem Boilercode-Kommentar (so nenne ich das mal) eigentlich nur 2 Dinge relevant: Es wird keine leere Liste, sondern NULL zurückgegeben und es gibt eine Exception. Mein "Einwurf" war, das man (ich) nicht au Teufel komm raus kommentieren soll(te), wenn es eh offensichtlich ist.

Eine "Beschreibung" der Methode in eine Handzahl Wörtern, welche sich bereits in der Signatur wiederfinden.. das ist nicht immer, aber oft nur eine Informationsredundanz.

Und nein, nicht für Java entschuldigt in dem Sinne. Aber Exceptions, Lists, Interfaces oder Variablen jetzt nicht so PHP-typisch, was wohl auf viele BG-Spiele zutrifft. Dennoch wollte ich mir jetzt nicht andere Beispiele ausdenken.

Als "Nichtprogrammierer" habe ich dazu eine zusätzliche Anmerkung, denn immerhin will ich meine Programmierer nicht mit jeder Kleinigkeit belästigen, sondern kleinere (und vor allem kleinste) Änderungen durchführen ohne vorher Rücksprache halten zu müssen.

Aus diesem Grunde lasse ich globale Berechnungsgrundwerte, Zeitwerte oder Einstellungen welche man im Laufe des Balancings immer mal wieder anpassen muss, immer in eine Konfigurationsdatei oder eine Konfigurationstabelle der Programmdb auslagern und "gut" kommentieren.
Dadurch kann ich wenn notwendig schnell mal eine Volltextsuche nach "tickzeit", "regenerationswert" oder "lebensenergie" starten und finde die entsprechenden Zeilen im Code recht flott. Ob das nun in Englisch oder Deutsch kommentiert ist, ist mir egal, hauptsache derartige dinge SIND kommentiert. Solltest du jemals einen Gamedesigner oder auch nur einen einfachen Spieladministrator im Boot haben, ersparst du dir (vorausgesetzt er ist kein DAU) viele nervtötende Fragen.

Derartiges kann man sich aber natürlich sparen, wenn der Code auch für einen "Laien" welcher das Programm an sich aber gut kennt/beherrscht lesbar ist. Ein Beispiel für so eine "Konfigurationsdatei" (auch wenn das Syntayhighlighting nicht passt):
http://pastebin.com/bkL78Zba

Definitiv sind solche ausgelagerten Konfigurationen wichtig, das kann man u.U. auch auf SQLs oder komplexe Formatierungsanweisungen ausweiten.

Allerdings ist die Nutzung solcher Konfigurationsansätze eher ein Design Pattern als ein Kommentierungsprinzip, oder?

Original von knalli

Allerdings ist die Nutzung solcher Konfigurationsansätze eher ein Design Pattern als ein Kommentierungsprinzip, oder?

Wie gesagt - ich bin kein Programmierer, sehe das also nicht aus diesem Standpunkt.
Doch auch wenn es eine ausgelagerte Konfiguration gibt, empfinde ich es als grundsätzlich äußerst nützlich, im Code auch für "Nichtprogrammierer" verständlich zu kommentieren (zumindest die Stellen die für den Nutzer oder "Admin" relevant sein könnten), - oder aber eine gute Doku zu schreiben. Mir persönlich ist eine Minidoku in Kombination mit verständlichen Kommentaren wichtig.
(Speziell für Konstrukte die später vielleicht einmal als Open Source freigegeben werden oder zur Lizensierung gedacht sind ist dies wohl sehr sinnig)
Ansonsten hast du selbstredend Recht knalli

Original von Bringer

Doch auch wenn es eine ausgelagerte Konfiguration gibt, empfinde ich es als grundsätzlich äußerst nützlich, im Code auch für "Nichtprogrammierer" verständlich zu kommentieren (zumindest die Stellen die für den Nutzer oder "Admin" relevant sein könnten)

Nichtprogrammierer sollten im Code nichts zu suchen haben. Wenn der Bedarf da ist dann wurde wahrscheinlich etwas falsch gemacht. Das Einzige was ich mir vorstellen kann sind irgendwelche Formeln. Wenn diese ständig geändert werden müssen, dann sollte man sie sehr gut auslagern innerhalb vom Code oder ganz aus dem Code in eine Konfigurationsdatei ziehen.

- oder aber eine gute Doku zu schreiben. Mir persönlich ist eine Minidoku in Kombination mit verständlichen Kommentaren wichtig.
(Speziell für Konstrukte die später vielleicht einmal als Open Source freigegeben werden oder zur Lizensierung gedacht sind ist dies wohl sehr sinnig)

Ich halte erstmal die API Dokumentation für das Wichtigste: Ich will in meiner IDE sehen was die Methode macht, was die Parameter sind und auf was ich achten muss ohne in den Code dieser Methode schauen zu müssen.

Zum Beispiel:

PHP:

/**
 * Dividiert den Divident durch den Divisor und liefert das Ergebnis zurück
 * @param integer|float $divident
 * @param integer|float $divisor
 * @return integer|float
 * @throws ArithmetikException Ausnahme wenn Divisor 0 ist
 */
public function division($divident, $divisor) {
   ...
}

Inlinekommentare finde ich nur in speziellen Bereichen sinnvoll, etwa komplexe Algorithmen sollten dokumentiert werden. Ansonsten sollten Variablen- und Methodennamen so gewählt werden dass der Code selbst so aussagekräftig ist dass er selbst die Dokumentation darstellt.

Zum Beispiel:

PHP:

$neuerSaldo = $alterSaldo + $einzahlung;
updateSaldo($neuerSaldo);

Die Zeilen sind so Aussagekräftig, dass eine Kommentierung keinen Mehrwert mehr bringt. Also ist eine Kommentierung hier nicht nur überflüssig, sondern schadhaft weil sie eine Fehlerquelle darstellt (etwa wenn der Code geändert wird und die Kommentierung nicht).

Nichtprogrammierer sollten im Code nichts zu suchen haben

Seh ich auch so das hat mit dem eigentlichen Kommentieren nix mehr zu tun. Einstell/Konfigurationen sollten übers Adminpanel möglich sein. In Konfigurationdatein hat der End abnehmer/Kunde nix verloren. Damit wird sicher gestellt das keine falschen Einstellungen möglich sind und auch der Kunde sich nix unbewußt zerstören kann.

Schon allein das abspeichern im falschen Datei Format kann zu fehlern führen (von Utf8 auf Iso unsw)

Mfg Splasch

Konfig-Dateien können das schon ruhig sein. Jedoch sollte es eine einfache Oberfläche geben, mit der man sowas einstellen kann.

Kunden sind unheimlich kreativ, wenn es darum geht Conf-Dateien zu zerdeppern.

Original von Kampfhoernchen

Konfig-Dateien können das schon ruhig sein. Jedoch sollte es eine einfache Oberfläche geben, mit der man sowas einstellen kann.

Kunden sind unheimlich kreativ, wenn es darum geht Conf-Dateien zu zerdeppern.

 Besonders wenn sie gemerkt haben, dass die Config-Dateien ausgeführt werden und man was darin programmieren kann.

Original von TheUndeadable

Original von Kampfhoernchen

Konfig-Dateien können das schon ruhig sein. Jedoch sollte es eine einfache Oberfläche geben, mit der man sowas einstellen kann.

Kunden sind unheimlich kreativ, wenn es darum geht Conf-Dateien zu zerdeppern.

 Besonders wenn sie gemerkt haben, dass die Config-Dateien ausgeführt werden und man was darin programmieren kann.

 *schütteln* Boah, sprich sowas bloß nie mehr an ;)

Wenn wir schon dabei sind wie Kommentiert ihr den Header Beispiel:

PHP:

/**
 * Datei mit PHPDoc-Testkommentar
 *
 * @package test
 * @author ich
 * @version 0.1
 * @copyright keins
 */
 

Und wie Kommentiert ihr Erweiterungen fremder Scripts also 2 verschiedene Authoren.

Gefunden dazu hab ich noch logenden Link siehe Tabelle 39.1

http://openbook.galileocomputing.de/joomla15/joomla_39_mein_erstes_modul_002.htm 

Hier werden ein paar Begriff erläutert:

PHP:

/**
* @ description
* @ name
* @ author
* @ version
* @ license
* @ copyright (c)
*/

Bei neuen Files sieht das dann bei mir so aus.

PHP:

/**
* @description Test Datei 
*
* @file test
* @date 2010
* @author test
* @version 0.1
* @copyright (c) test
*/

 Was fügt ihr bei änderungen (update) oder Erweiterungen dem hinzu wenn ihr selbst nicht der Ursprungs Author seit?

Bei mir kommen in den Header nur Angaben die die Datei beschreiben. Also @package und @licence vor allem. Angaben zu Autor und Version haben bei mir dort nichts zu suchen, dafür gibt es SVN und Co.

:D ich habe garkeine allgemeinen kommentare.. ich versuche alles so zu programmieren, dass es selbsterklärend ist .. die meisten kommentare habe ich in der eigentlichen methode drin um eine spezielle zeile schnell wieder nachvollziehen zu können... da ich alleine programmiere halten mich die kommentare nur auf.. vor allem früher als ich die methoden ncoh beschreiben habe usw,musste ich viele wieder neu tippen weil sich einiges im quellcode getan hat.. war mir zu umständlich... aber wie gesagt ich programmier alleine und denke es wird sich nicht bald ändern:D

Ob man alleine entwickelt oder nicht ist egal, der Quellcode sollte auch für Aussenstehende gut lesbar und verständlich sein. Ob der Quellcode durch geeignete Methoden und Variablennamen selbsterklärend ist oder Kommentierungen braucht ist dann ein anderes Thema.

Grund: Nach ein paar Wochen/Monaten ohne Anpassungen an den Stellen bist du selbst ein Aussenstehender weil keine Ahnung mehr hast was du warum wie gebaut hast. Dann hält es ungemein auf wenn man für jede Änderung sich wieder in alten Code einlesen muss.

Original von DrakeL

Grund: Nach ein paar Wochen/Monaten ohne Anpassungen an den Stellen bist du selbst ein Aussenstehender weil keine Ahnung mehr hast was du warum wie gebaut hast. Dann hält es ungemein auf wenn man für jede Änderung sich wieder in alten Code einlesen muss.

ja aus diesen grund kommentiere ich nur schwer verständliche zeilen im quellcode eine beschreibung einer methode sowie übergabe parameter und returnwerte sind eigentlich relativ egal.

der Quellcode sollte auch für Aussenstehende gut lesbar und verständlich sein.

Naja es geht niemanden was an, was im hintergrund läuft:D Ich blinke auch nicht beim autofahren, es geht ja auch niemanden was an wohin ich fahren will:D

ich finde wenn ich soviel zeit in das auskomentieren investiere, dann komme ich noch weniger voran als jetzt.. wie gesagt in meinem fall dienen kommentare nur als denkstütze damit ich mich halt später erinnern kann was da eigentlich passiert..

Original von BlackScorp

ja aus diesen grund kommentiere ich nur schwer verständliche zeilen im quellcode eine beschreibung einer methode sowie übergabe parameter und returnwerte sind eigentlich relativ egal.

Also ich finde es immer hilfreich wenn ich aufgezeigt bekomme was die Methode macht, wofür die Parameter sind und was die Methode zurückgibt. Und das ohne in die Methode schauen zu müssen dank API Kommentar. Das sollte das Minimum sein an Kommentierung.

der Quellcode sollte auch für Aussenstehende gut lesbar und verständlich sein.

ich finde wenn ich soviel zeit in das auskomentieren investiere, dann komme ich noch weniger voran als jetzt.. wie gesagt in meinem fall dienen kommentare nur als denkstütze damit ich mich halt später erinnern kann was da eigentlich passiert..

Du hast mein den Grund wohl nicht gelesen warum ich das sage. Du bist selbst ein Aussenstehender wenn du den Quellcode längere Zeit nicht anfassen musstest. Und ich investiere lieber beim Schreiben mehr Zeit als bei jeder Änderung die Zeit ins Einlesen investieren zu müssen.

Wobei ich eher dafür bin den Quellcode selbsterklärend zu schreiben (geeignete Modularisierung, Variablennamen usw.) und die Kommentierung auf das Nötigste (API Kommentare) zu beschränken. Inline Kommentare finde ich nur selten notwendig.

ja natürlich klingt das alles logisch usw... aber wenn ich mir die praxis so anschaue.. in der firma kriege ich eine vorgabe wann eine software fertig sein muss und wann die doku dazu stehen muss. am ende liefer ich eine fertige exe innerhalb des zeitraumes ab , die anwender doku dazu und fertig.. ich würde niemals mit der zeit hinkommen wenn ich da noch kommentare reinsetzten müsste

Dass Firmen die Schwerpunkte woanders hinlegen ist normal. Bei vielen Firmen heisst es keine Zeit für Planung / Dokumentation / Testen es muss ja schnell fertig werden. Hat aber meist den Nachteil dass man wesentlich mehr Zeit hinterher braucht wenn es darum geht die Software stabil zu machen oder anzupassen.

Privat nehme ich mir deswegen lieber mehr Zeit und mache es ordentlich. ;)

Original von DrakeL

Privat nehme ich mir deswegen lieber mehr Zeit und mache es ordentlich. ;)

Genau DAS ist der punkt... es gibt keine besten kommentare oder schlechtesten kommentare oder eine bestimmte syntax, reihenfolge oder vorschrift... es kommt jedesmal auf das Projekt an und die anforderung dazu habe nur ein wenig drumherum geredet weil.. lange weile und so..

Wenn das Ergebnis nach aussen hin für die User stimmt und man selber mit fehlenden Kommentaren klarkommt, ist es halt ziemlich egal.

Hauptsache das für den Spieler sichtbare Ergebnis stimmt.

Es geht ihr weniger im Thema ob man Kommentieren soll oder nicht. Sondern wie man das am besten Kommentiert. Daher stellt sich eigentlich garnicht die Frage ob man Kommentieren soll oder nicht. Der/die jenige/n die nicht Kommentieren möchten haben meiner Meinung nach auch hier in diesen Thema nix verloren.

Authoren angaben könnten durch aus wichtig sein um festzustellen wer nun anrechte auf diesen Teil bzw Script hat. Der Urheber hat die Möglichkeit das ganze unter einer Lizens freizugeben. Wenn man aber nicht mal weiß wer das geschrieben hat wird man ihn schlecht fragen können ob man es verwenden darf.

Wird troztdem ohne rückfrage oder Liezens dieses verwendet bewegt man sich in der Grauzone. Finds nur schade das es hier nur zugespamt wird mit nein und ja für Kommentieren. Und sich mit der eigentlichen Frage überhaupt nicht beschäftigt wird.

Original von BlackScorp

ja natürlich klingt das alles logisch usw... aber wenn ich mir die praxis so anschaue.. in der firma kriege ich eine vorgabe wann eine software fertig sein muss und wann die doku dazu stehen muss. am ende liefer ich eine fertige exe innerhalb des zeitraumes ab , die anwender doku dazu und fertig.. ich würde niemals mit der zeit hinkommen wenn ich da noch kommentare reinsetzten müsste

 Kleiner Tipp: Du machst Dir eh Gedanken darüber, welche Aufgaben welche Teile der Software haben. Schreib' das einfach kurz in die Klassen / Funktions-Deklaration mit rein. Welche Aufgaben hat eine Klasse (ggf. welche eben nicht), was macht eine öffentliche Funktion Deiner Klasse. Ich kann mir das meistens eh nicht von Freitag auf Montag merken und das gehört bei mir in den Arbeitsschritt design und die Information wird eh spätestens bei Unit-Test benötigt, sonst weis ich überhaupt nicht, was ich testen soll.

Soll sagen: Die Gedanken musst Du Dir eh machen, das dauert in der Regel deutlich länger, als das Ergebnis kurz zu fixieren. Im Nachhinein sieht man nur noch Deine Software und beurteilt Dich daran, nicht wie viel Zeit Du dafür bekommen hast. Irgend wann sagt einer: "den Sch.. müssen wir neu machen, der Kollege hat da unwartbare Software hinterlassen".

mfg Torsten

Original von splasch

Authoren angaben könnten durch aus wichtig sein um festzustellen wer nun anrechte auf diesen Teil bzw Script hat. Der Urheber hat die Möglichkeit das ganze unter einer Lizens freizugeben. Wenn man aber nicht mal weiß wer das geschrieben hat wird man ihn schlecht fragen können ob man es verwenden darf.

Ich finde es etwas weltfremd, davon auszugehen, dass man ganze Dateien bestimmten Entwicklern zuordnen könnte. In der Regel wird immer ein Kollege etwas an Deinem Kode ändern müssen und Du etwas an seinem und das ist auch gut so. Wenn Du wirklich wissen möchtest, wer welche Kode beigesteuert hat, dann verwende einfach eine Quellcode-Verwaltung, die haben in der Regel so etwas wie "blame" bei svn, was einem ganz genau sagt, welche Zeile der betrachteten Version von wem ist.

Wird trotzdem ohne rückfrage oder Liezens dieses verwendet bewegt man sich in der Grauzone. Finds nur schade das es hier nur zugespamt wird mit nein und ja für Kommentieren. Und sich mit der eigentlichen Frage überhaupt nicht beschäftigt wird.

Scheint so, als hättest Du eine sehr konkrete Frage auf die Du Dir durch Starten eines Ballons eine Antwort erhofft hast, diese aber nicht erhältst. Urheberrechte spielen bei Kommentaren eigentlich eine nur sehr untergeordnete Rolle, weil Kommentare keine Urheberrechte begründen, sie bestenfalls dokumentieren, aber auf keinen Fall beweisen. Ich finde die Diskussion übrigens ganz interessant.