Bezeichnungen und Kommentare

[vanny]

SO,
vorweg erstmal die Information, dass ich eigentlich Hobby- und FreizeitJavarer bin und daher nicht in den Genuß komme, mit professionellen Teams zu arbeiten.(zumind. bis jetzt noch nicht).
Ich habe vor einiger Zeit mit Javalernen begonnen, weil ich auf Arbeit alle 2 Monate über 1000 Bilder manuell raussammeln und umbenennen musste. Schon 3 Monate später hatte ich mein eigenes Tool, das diesen Job bis heute in wenigen Sekunden erledigt und mir sogar ein Fehlerprotokoll ausspuckt.
Mein Chef hats gesehn und kam dann gleich mit "mach mal noch dies und das ^^".(War bisher auch nicht zu meinem Schaden).

Ok, nun zum eigentlichen Problemchen.
Kennt jemand eine gute Seite, in der man sieht wie richtig Kommentiert wird?(wann, wie, wo, warum, etc.)?
Und wie schlimm ist es, die deutsche Sprache zu benutzen?(Ich versuch die 100% Englisch zu wahren, ertappe mich aber immer wieder beim Kuddelmuddel, was Form und Sprache angeht.)

Naja und Google is da auch eher ein Urwald als ein gepflegter Garten, deshalb frag ich hier einfach mal rein.

Nich haun:autsch:

Gruß Vanny

 

[njans]

Also du solltest dich fragen: Kann man jemals genug kommentieren?
Prinzipiell sollte man es dem Lesenden eben so genau wie nötig erklären.

Was genau willst du denn wissen?

 

[maki]

Also du solltest dich fragen: Kann man jemals genug kommentieren?

Klar, Inline Kommenatare (also alles was nicht JavaDoc ist) gelten als Code-Smell.
Auch mahct es meist wenig Sinn private Methoden/Variablen zu kommentieren.
Wichtig ist dass die JavaDoc erklärt was gemacht wird, nicht wie, letzteres steht in der Implementierung.
Eine Ausnahme wären zB. math. Algorythmen.

Gute Bezeichner für Variablen und Methoden und eine saubere Struktur zu wählen ist besser als zu versuchen schlecht geschriebenen Code zu dokumentieren.

Die Frage nach "guter Kommentierung" ist imho nix anderes als die Frage nach sauberem Code und wird imho am besten von Robert Martin in seinem Buch "Clean Code" beantwortet.

Auf Deutsch sollte verzichtet werden.

 

[freez]

Auch mahct es meist wenig Sinn private Methoden/Variablen zu kommentieren

HM??
Private Methoden sollten dokumentiert sein ... vor allem wenn dort komplexere Dinge passieren. Klar kann man sich überlegen, ob man einfache private Methoden nicht kommentiert, da sich der Inhalt schnell erschliesst. Allerdings muss man bei komplexeren Methoden schon an seine Kollegen denken, bzw. an sich selbst, wenn man ein Jahr später drüber schaut.
Private Member sind vielleicht nicht unbedingt nötig. Schaden würde es aber nicht, warum es als Member einer Klasse definiert ist.

Kommentieren ist eine schwierige Sache ... wenn man sich nicht selbst zwingt durchgängig mit Kommentaren zu arbeiten, treten schnell "Kommentarlöcher" auf, die immer größer werden. Somit würde ich empfehlen, lieber einmal unnötig, als Löcher.

Ausserdem vielleicht ein kurzes Statement zum Inhalt von Kommentaren im Code selber, wenn man beschreiben möchte, was hier passiert: Wenn man irgendwo ließt "Hole Tabelle 'X' aus Datenbank" ist dies in der Regel absolut unnötig, weil einem Entwickler sich die Zeilen in der Regel erschliessen, und man erkennt, dass da jemand "Daten aus einer Tabelle 'X' holen wollte". Besser wäre wohl eher sowas wie "//Hole Werte zu Kundenaufträge, welche in den letzten 4 Wochen gebucht worden und von Neukunden stammen, damit sie der Buchhaltung in den Auftragsvorrat zur Bearbeitung gelegt werden können". Also besser das Wieso und Was dokumentieren, als in Deutsch zu schreiben, was in Java schon da steht.

 

[bygones]

Also du solltest dich fragen: Kann man jemals genug kommentieren?

oh ja kann man. Wie maki schon sagt, je mehr inline kommentare hat umso mehr sollte man sich ueber den code selber Gedanken machen. Ich persoenlich halte auch nichts von javadocs zu simplen settern/gettern ala

/**
 * Sets the age
*/
public void setAge(int age) { 
/...

ist nichtssagend und code aufblaehend.
Also man kann leicht zu viel kommentieren.

Ebenso wenn man Methoden hat bei denen man anfaengt ala "macht das und das und das und das" - sobald unds in Kommentaren vorkommen ist das auch ein Zeichen fuer Coderefactoren.

Ansonsten - "Clean Code" ist da wohl der Klassiker.

Ich finds ok wenn deutsch kommentiert wird, wenn die "Zielrgruppe" rein deutsch ist. Meine fruehere Firma hat nur fuer dt Kunden entwickelt, die Belegschaft war dt - warum da englisch reinbringen ?!

HM??
Private Methoden sollten dokumentiert sein ... vor allem wenn dort komplexere Dinge passieren.

private Methoden sind implementierungsdetails, diese brauchen keine Javadoc. Wenn komplexe dinge geschehen sollte der Code dies gescheit wiederspiegeln, so dass man keine Kommentare braucht.
Ich stimme maki da zu, oeffentliche Schnittstellen muessen dokumentiert werden, private nicht.

 

[faetzminator]

Kann das meiste der Vorredner akzeptieren, bestätigen.

Klar, Inline Kommenatare (also alles was nicht JavaDoc ist) gelten als Code-Smell.

Meiner Meinung nach benötigt man in Java tatsächlich fast nie Inline Comments, aber seit ich zehnzeilige "JQuery-Funktionen" in JS schreib, bin ich froh darum (oder wer mag sich 2 Wochen später daran erinnern, warum nun [c].foo td:first .bla>a:first[/c] selektiert wurde?).

 

[freez]

private Methoden sind implementierungsdetails, diese brauchen keine Javadoc. Wenn komplexe dinge geschehen sollte der Code dies gescheit wiederspiegeln, so dass man keine Kommentare braucht.

Also hier muss ich widersprechen. Ein und dieselben Codezeilen kann ich aus unterschiedlichen Gründen ausführen. Vor allem, wenn man mit Daten aus externen Quellen arbeitet, sollte schon da stehen, was dieser Code bezwecken sollte. Wenn jemand anderes später die Zeilen debuggen muss ist es schon toll zu wissen, ob das, was passiert auch genau das ist, was der Ersteller sich dabei gedacht hat. Ich rede hier aber unbedingt von Kommentaren innerhalb von Methoden. Bei JavaDoc Kommentaren für private Methoden bin ich zwie gespalten. Manchmal kann es schon Sinn machen, aber in der Regel sollte der Aufruf dieser Methode selbsterklärend, oder kommentiert sein, sodass man hier kein JavaDoc braucht.

 

[casi91]

Klar, Inline Kommenatare (also alles was nicht JavaDoc ist) gelten als Code-Smell.
Auch mahct es meist wenig Sinn private Methoden/Variablen zu kommentieren.
Wichtig ist dass die JavaDoc erklärt was gemacht wird, nicht wie, letzteres steht in der Implementierung.
Eine Ausnahme wären zB. math. Algorythmen.

Hier gehen unsere Meinungen auseinander.
Also ich habe gelernt (und bin auch immernoch der Meinung), sobald eine Methode (egal ob private oder public) komplexer wird und ein anderer Programmierer (oder man selbst) viel Zeit braucht um zu verstehen was in dieser Methode abläuft, sollte auch das "wie" ein wenig dokumentiert sein.

Jetzt muss das aber nicht unbedingt durch inline-Kommentare geschehen. Man kann sich bei solchen Sachen ja auch noch mit UML-Diagrammen weiter helfen.
Ein Activity-Diagramm bei einer komplexen Methode, ist meiner Meinung nach das aussagekräftigste und am schnellsten verständlichste Mittel um sich in eine Methode einzuarbeiten.

Ich bin aber ebenfalls der Meinung, dass die Kommentierung der Getter/Setter den Code eher unnötig aufbläht und nicht hilfreich ist, hier sollte allein der Name aussagekräftig genug sein, ist dies nicht der Fall sollte man sich gedanken über die Namensgebung machen.

 

[ARadauer]

Diese Unterscheidung zwischen private nicht dokumentieren und public unbedingt dokumentieren finde ich nicht gut.
Ich finde es kommt drauf an was ich programmiere. Entwerfe ich ein Framework oder eine API wo dem Benutzer eigentlich egal sein sollte was im inneren passiert, macht es wenig Sinn private Methoden zu dokumentieren. Da das nicht Teil der Schnittstelle ist.
Ich dokumentiere jedoch nicht nur für Benutzer meiner API sondern auch für Kollegen oder für mich die die API und Implementierungsdetails weiterwentwicklen. Da macht es auf jedem fall Sinn komplexere private Methoden zu dokumentieren.
Wobei Martin hat in Clean Code schon recht. Wenn ich es dokumentieren muss, muss ich mir zu erst überlegen ob ich es nicht einfacher programmieren kann. Oft geht das halt nicht, dann bin ich froh wenn komplexere Stellen im inneren Meiner Klasse auch dokumentiert sind.

 

[tfa]

Also ich habe gelernt (und bin auch immernoch der Meinung), sobald eine Methode (egal ob private oder public) komplexer wird und ein anderer Programmierer (oder man selbst) viel Zeit braucht um zu verstehen was in dieser Methode abläuft, sollte auch das "wie" ein wenig dokumentiert sein.

Dann sollte man sich zuerst fragen, warum eine Methode komplexer geworden ist. Vielleicht lohnt es sich dann, Refactoring zu betreiben und die Funktionalität in mehrere kleine Methoden aufzuspalten. Wenn man sich dann noch sinnvolle Namen für diese Methoden überlegt, ist das praktisch schon die Dokumentation.

 

[bygones]

Also ich habe gelernt (und bin auch immernoch der Meinung), sobald eine Methode (egal ob private oder public) komplexer wird und ein anderer Programmierer (oder man selbst) viel Zeit braucht um zu verstehen was in dieser Methode abläuft, sollte auch das "wie" ein wenig dokumentiert sein.

da ist aber kommentar der falsche Ansatz sondern das aufbrechen der Komplexitaet.

Also hier muss ich widersprechen. Ein und dieselben Codezeilen kann ich aus unterschiedlichen Gründen ausführen. Vor allem, wenn man mit Daten aus externen Quellen arbeitet, sollte schon da stehen, was dieser Code bezwecken sollte. Wenn jemand anderes später die Zeilen debuggen muss ist es schon toll zu wissen, ob das, was passiert auch genau das ist, was der Ersteller sich dabei gedacht hat

Eine Funktionalitaet sollte eine Sache machen, wenn sie in verschiedenen Kontexten ausgefuehrt wird ist das nicht die Verantwortung der Methode. Die Methode sollte nicht dokumentieren aus welchen Gruenden sie aufgerufen wird (woher soll sie das wissen).

Ich finde es kommt drauf an was ich programmiere. Entwerfe ich ein Framework oder eine API wo dem Benutzer eigentlich egal sein sollte was im inneren passiert, macht es wenig Sinn private Methoden zu dokumentieren. Da das nicht Teil der Schnittstelle ist.

Die Unterscheidung find ich hier falsch. JEDER Code den du erstellst ist API. Deine Kollegen sollten ebenso nur die API nutzen und nicht Implementierung. Falls der Kollegen am selben Code arbeitet weil in einem Team oder so, dann gilt ebenso: Besserer Code vermindert den Bedarf von Kommentaren.

Die allgemeine Faustregel ist:

Brauch ich inline kommentare soll ich mir Gedanken machen ob man den Code nicht sprechender machen kann.

Das natuerlich schliesst nicht aus, dass man keine inline Kommentare verwendet - natuerlich gibt es sie und man kann sie nutzen, man sollte es aber nicht brauchen

 

[Firephoenix]

Man merkt beim Durchlesen dieses Threads sehr genau wo Robert C. Martin zugeschlagen hat

In dem Punkt "komplexe Methoden sollten besser benannt oder in kleinere Methoden aufgeteilt werden, anstatt einen Kommentar einzusetzen" gebe ich euch recht, es gibt allerdings eine Kommentar-(nicht javadoc!)form die man leider selten findet, aber oft hilfreich ist wenn man sie braucht und findet:
Kommentare über Designentscheidungen die Dokumentieren warum man an der Stelle Lösung X anstatt Lösung Y verwendet hat. Wenn man als Entwickler seine Ideen ebenfalls mit einfließen lässt macht es anderen Entwicklern einfacher weiterzuarbeiten.

Gruß

 

[bygones]

Kommentare über Designentscheidungen die Dokumentieren warum man an der Stelle Lösung X anstatt Lösung Y verwendet hat. Wenn man als Entwickler seine Ideen ebenfalls mit einfließen lässt macht es anderen Entwicklern einfacher weiterzuarbeiten.

Designentscheidungen als kommentar im source code ?! na ich weiss nicht

 

[Firephoenix]

Ich meine damit jetzt nicht Designentscheidungen wie z.B. wann wo welches Pattern eingesetzt wurde oder wie man seine Module trennt, sondern z.B. stellen bei denen innerhalb einer Methode der Code auf den ersten Blick anders aussieht oder die lösung vielleicht einfach zu verstehen, aber nicht klar ist warum keine andere verwendet wurde. Ein Beispiel das mit selbst untergekommen ist: jemand brauchte Permutationsvorlagen und hat diese auf basis eines boolean-arrays erzeugt, ohne kommentar darüber das er die boolean-arrays als template fürm permutationen benutzt sah der code echt merkwürdig aus - aber man konnte die lösung nachvollziehen, bzw die idee von demjenigern der den code geschrieben hat (war an der stelle auch durch die Methodennnamen und variablennamen nur schwer verbesserbar)


Gruß

 

[maki]

Ich meine damit jetzt nicht Designentscheidungen wie z.B. wann wo welches Pattern eingesetzt wurde oder wie man seine Module trennt, sondern z.B. stellen bei denen innerhalb einer Methode der Code auf den ersten Blick anders aussieht oder die lösung vielleicht einfach zu verstehen, aber nicht klar ist warum keine andere verwendet wurde.

Architektur- und Designentscheidungen sollten imho auch woanders dokumentiert werden (Excelsheet, Issuemanagementsystem, etc. pp.), warum Framework A und nicht Framework B etc. pp.
Ist imho wichtig wenn sich Vorraussetzungen/Anforderungen ändern, sonst verpasst man u.a. schnell die Möglichkeit solche Entscheidungen anzupassen wenn sich was ändert, ohne Niederschrift weiss man irgendwann gar nciht mehr warum etas so gemacht wurde wie es gemacht wurde.

Ein Beispiel das mit selbst untergekommen ist: jemand brauchte Permutationsvorlagen und hat diese auf basis eines boolean-arrays erzeugt, ohne kommentar darüber das er die boolean-arrays als template fürm permutationen benutzt sah der code echt merkwürdig aus - aber man konnte die lösung nachvollziehen, bzw die idee von demjenigern der den code geschrieben hat (war an der stelle auch durch die Methodennnamen und variablennamen nur schwer verbesserbar)

Das klingt doch nach einem math. Algorythmus -> Ausnahme
Ansonsten eben immer das was beschrieben bei public/protected Methoden/Variablen, nicht das wie, denn das steht ja im Code, wäre sonst rdundant und irgendwann würde die Doku nicht mehr den eigentlichen Code beschreiben.

private Methoden/Variablen eine JavaDoc verpassen... JavaDoc ist Dokumentation die generiert wird, JavaDoc erzeugt per default keine Doku für private Methoden/Variablen, warum wohl?

Ansonsten finde ich persönlich es am schlimmsten, wenn man dogmatisch immer & überall Javadoc hinschreibt (zB. an private Methoden/Variablen), muss das schon mit Vernunft angehen und sehen, ob die Doku wirklich Informationen hinzufügt, ansonsten besser weglassen.
Bei gut gewählten Bezeichnern fügt eben die JavaDoc oft selten einen Mehrwert hinzu, besonders bei Variablen.
Irgendwer hat mal gesagt es wäre Zeitverschwendung schlecht geschriebenen Code zu dokumentieren..

Komplexe Methoden?
Wie komplex kann eine 3 Zeilen lange Methode schon sein?
Was ich von langen Methoden halte hab ich ja schon mehrfach an anderer Stelle geschrieben.
Auch hier bilden Algorythmen eine Ausnahme.
Wie gesagt, Doku Stil hängt eng mit dem Code Stil zusammen...

 

[casi91]

Komplexe Methoden?
Wie komplex kann eine 3 Zeilen lange Methode schon sein?
Was ich von langen Methoden halte hab ich ja schon mehrfach an anderer Stelle geschrieben.
Auch hier bilden Algorythmen eine Ausnahme.

Ich habe mich eben mit "Komplexe Methoden" vielleicht ein wenig unsauber ausgedrückt.
...Was heißt vielleicht..es war unsauber

Damit meinte ich die von dir angesprochenen Algorythmen.
Entschuldigung dafür.

 

[Firephoenix]

Architektur- und Designentscheidungen sollten imho auch woanders dokumentiert werden (Excelsheet, Issuemanagementsystem, etc. pp.), warum Framework A und nicht Framework B etc. pp.
Ist imho wichtig wenn sich Vorraussetzungen/Anforderungen ändern, sonst verpasst man u.a. schnell die Möglichkeit solche Entscheidungen anzupassen wenn sich was ändert, ohne Niederschrift weiss man irgendwann gar nciht mehr warum etas so gemacht wurde wie es gemacht wurde.

Ich hätte Code-Entscheidungen anstatt Designentscheidung schreiben sollen
Dein Post bringt es aber nochmal ziemlich gut auf den Punkt (Architekturentscheidungen als Kommentar im Code unterzubringen wäre in etwa so als würde man auf der Scheibenwischanlage eines Autos eine Plakette mit der Aufschrift "Allradantrieb für schwieriges Gelände" ankleben)

(Eben mal Clean Code rausgekramt, die Kommentare auf die ich mich eigentlich beziehen wollte bezeichnet C. Martin als "Explanation of Intent")

Gruß

 

[vanny]

Ui, so viele posts ^^.
Ok ich danke euch erstmal allen, für die freundliche Disskusion bis hierhin und stelle fest, es gibt also keine Konvetntion in diesem Sinne und es richtet nach Komplexität und Erklärungsbedarf. Ist nicht neu für mich aber einige neue Einblicke konnte ich doch für mich gewinnen.

Ich spar mir jetzt das Durchklicken der Dankebuttons (wer´s unbedingt braucht soll bescheid sagen^^) und lasse das Thema noch ein wenig offen, es geht hier ja vielleicht noch ein wenig weiter

Gruß Vanny

PS: werd mir wohl mal Clean Code zulegen :rtfm:

 

[maki]

Damit meinte ich die von dir angesprochenen Algorythmen.
Entschuldigung dafür.

Es gibt keinen Grund sich zu entschuldigen, wir diskutieren ja nur

Wollte nur noch mal darauf hinweisen, dass ich eigentlich "mathematische Algorythmen" meinte und nicht "allgemeine Algorythmen".

 

[Marco13]

Das heißt nicht "Algorythmen", sondern "Allgorühdmän"... oder so ähnlich.

Manchmal heißt es ja: Kommentiere den Code so, als ob derjenige, der den Code nachvollziehen und weiterpflegen muss, ein psychopathischer Kettensägenmörder ist, der weiß, wo du wohnst

Wie? Da gehen die Meinungen in den Details ja auseinander - eben dort, wo es subjektiv wird, wenn man den allgemeinen Konsens ("So kommentieren, dass es sinnvoll ist" :autsch: ) etwas weiter zerpflückt.

Es irritiert mich manchmal, dass bestimmte Sachen (unbegründet ???:L ) als "gut" oder "schlecht" dargestellt werden. Inline Kommentare? Ja, kann sinnvoll sein: Ein, zwei Zeilen a la

// Now we do this-and-that. We use the FooBar allgorühdmuß
// here, because it has this-and-that nice property

können nicht schaden, und machen den Code auch nicht unübersichtlicher - zumindest nicht unübersichtlicher, als drei Zeilen krampfhaft in eine private Methode auszulagern, die 10 Parameter übergeben bekommen muss, an einer anderen Stelle der Datei steht, und nur an dieser einen Stelle aufgerufen wird.
Private Fields/Methoden mit JavaDoc kommentieren? Und protected? Und default? Und wenn es wirklich nur ein setter ist? Ich mach' mir das Leben da einfach: Ich kommentiere ALLES. (Punkt). Ja, es sieht manchmal blöd aus

/**
 * The text field that contains the name
 */
private final JTextField nameTextField;

/**
 * Set the name
 * 
 * @param name The name
 */
public void setName(String name)
{
    this.name = name;
}

aber man erspart sich die Abwägungen und den subjektiven Kram, und schon ein
[c]Set the name. This may never be 'null'[/c]
rechtfertigt das IMHO. Oder allgemeiner für private Methoden: Man kann (und sollte) Vor- und Nachbedingungen angeben. Nicht unbedingt "formal", aber im Sinne von Hinweisen darauf, welche Annahmen über Parameter gemacht werden oder wann die Methode aufgerufen werden darf.

Einen wichtigen Punkt sollte man aber (auch in bezug auf Aussagen, dass man bestimmte Dinge ja "nicht unbedingt kommentieren muss, weil... ... ...") berücksichtigen: Kommentare haben IMHO eben NICHT nur den Zweck, Kommentare zu sein. Sie sind eine Form der Reflexion: Wenn man ansetzt, einen Kommentar für ein Field, eine Methode, oder ganz besonders eine Klasse zu schreiben, und sich denkt: "Joa, was das ist, kann ich nicht so genau benennen, und was es macht kaum in einem Satz beschreiben", dann ist das der erste Schritt auf dem Weg zu besserem Code. (Klar kann man das theoretisch auch, OHNE zum Schreiben des Kommentars anzusetzen, aber es hilft)

 

[bygones]

Marco - zu meinen manches wird hier unbegruendet dargestellt und dann eine Art Polemik ueber 10 parameter methoden zu nennen ist auch nicht gerade sinnvoll ;-)

niemand sagt dass inline Kommentare verboten sind, die Aussage ist dass das, was sie aussgen sollen, mit besseren Moeglichkeiten eindeutiger und verstaendlicher kommuniziert werden koennen.

Zu deiner letzten Aussage (sowohl die bedingung als auch die Reflexion): Das bekommt man mit Tests besser hin und man hat dann auch noch seine Tests.

Kommentare KOENNEN das alles rueberbringen, sie sind aber meiner Ansicht nach einfach die falsche Medizin....

 

[Marco13]

Wäre "mehrere" besser (und weniger polemisch) gewesen als "10"?

Das "unbegründet" bezog sich darauf, dass ich in Analogie zum "Code Smell" gelegentlich einen "Thread Smell" feststelle, der sich darin äußert, dass irgendjemand berühmtes oder wichtiges mal irgendwo was geschrieben hat, und das dann sklavisch-unreflektiert wiedergekäut wird.

Als (polemisches? ) Beispiel: Fowler sagt, dass lange Methoden ein Code-Smell sind. Kondensiert wird das oft zu ~"Man sollte lange Methoden vermeiden". Und ins Extreme geführt wird das dann mit "Jede Methode mit mehr als 5 Zeilen ist BÖSE! " . Aber Fowler sagt auch: "Some long methods are just fine". Wenn eine Methode 300 Zeilen hat, und 150 davon Inline-Kommentare sind, sollte man überlegen, ob da vielleicht was nicht stimmt. Aber man kann auch zu dem Schluss kommen: Joa, das ist ein Sonderfall, und in Ordnung so.

Es stimmt, dass in vielen Fällen Tests die angedeutete Funktion (Anlaß zur Reflexion) erfüllen können. Aber vielleicht liegt es auch in erster Linie an der Persönlichkeit, der Dispiziplin und den Denkstrukturen des Entwicklers. Wer eine Klasse

class PersonAndCar
{ 
    public int deleteAndExist(boolean not) { ... }
}

schreibt, den hindert auch nichts daran, Kommentare

/*
 * A person and a car
 */
class PersonAndCar
{ 
    /*
     * Delete and exist. 
     * @param not Whether it should not be done
     * @return The index
     */
    public int deleteAndExist(boolean not) { ... }
}

zu schreiben, oder Unit-Tests

assertTrue(pac.deleteAndExist(true) == 24);
assertFals(pac.deleteAndExist(false) != 42);

zu erstellen

 

[pappawinni]

Man hat dann auch noch seine Tests!?
Aha, ist dann irgendwo dokumentiert welcher Test da wofür ... aeh....und ...
Also ich hab mich schon bestimmt tausend mal geärgert, weil ich irgend einen alten Code in die Hand bekam den ich in ne andere Sprache umsetzten wollte/sollte, wo Null Kommentare drin waren. Klar erklärt sich Code irgendwie immer selbst, und irgendwer mag dafür auch mal irgendwann seine Tests gehabt haben. Nützt mir halt nix.

 

[bygones]

Man hat dann auch noch seine Tests!?
Aha, ist dann irgendwo dokumentiert welcher Test da wofür ... aeh....und ...

Implementierungsklasse mit suffix 'Test' ist der Test der entsprechenden Klasse, so einfach. Verschiedene Szenarien im Test erklaeren dir die versch Vor-NachBedingungen und das gewuenschte Verhalten.

Ist dein Code s******e, sind deine Tests s******e, dann bringts natuerlich nix, also sind solche destruktiven Kommentare unsinnig.

@Marco:
Nochmals - es gibt hier kein schwarz und weiss. Natuerlich gibt es zig zeilen lange Methoden, auch wenn sie es nicht geben sollte, natuerlich gibt es inline kommentare, auch wenn sie vielleicht nicht sein muessten. Fuer alles gibt es relevante und logische Erklaerungen.
Ich versteh beim besten WIllen nicht, wieso man bei solchen Clean Code Regeln immer von boesen Attacken ausgeht, die einer Diktatur gleichkommend einem aufdruecken was man zu tun hat und was nicht. Das ist Schwachsinn....

Egal - ich glaub alles wiederholt sich hier immer wieder, die Diskussion gabs vor langer Zeit schon, gibts wieder - anscheinend lernt keine der Seiten etwas dazu, daher wird es immer wieder so sein.

somit - bygones....

edit ist beeindruckt dass es echt einen Schimpfwortfilter hier gibt

 

[vanny]

edit ist beeindruckt dass es echt einen Schimpfwortfilter hier gibt

und Schade, dass man sowas benötigt;(

Ich klicke mal auf ERLEDIGT.

Danke euch allen
Vanny

 

[Marco13]

Nochmals - es gibt hier kein schwarz und weiss. ...

Ich versteh beim besten WIllen nicht, wieso man bei solchen Clean Code Regeln immer von boesen Attacken ausgeht, die einer Diktatur gleichkommend einem aufdruecken was man zu tun hat und was nicht.

Nun, so sehe ich das auch. Ich hatte lediglich angedeutet, dass es mir scheint, als würde gelegentlich eben diese Schwarzweißmalerei betrieben. Genauso wie die Aussage: "Methoden mit mehr als 10 Zeilen sind schlecht" falsch ist, ist die Aussage "Methoden mit mehr als 10 Zeilen als schlecht zu bezeichnen ist falsch" falsch Wenn das jedem klar wäre, wäre ja alles in Ordnung