Abo
  1. Foren
  2. Kommentare
  3. Applikationen
  4. Alle Kommentare zum Artikel
  5. › Computer History Museum…

Guter Code braucht keine Kommentare

Anzeige
  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Guter Code braucht keine Kommentare

    Autor: HansiHinterseher 15.02.13 - 10:36

    Das hat schon Bjarne Stroustrup mal gesagt.

    Wenn man kommentieren muss, dann weil der Code schlecht zu verstehen ist. Code muss sprechend sein, besonders mit den heutigen Hochsprachen sehr einfach.

    Bei Assembler-Programmen sind Kommentare eher verständlich. Wobei selbst Assembler heute schon sehr viele Möglichkeiten bieten, lesbareren Code zu schreiben...



    1 mal bearbeitet, zuletzt am 15.02.13 10:36 durch HansiHinterseher.

  2. Re: Guter Code braucht keine Kommentare

    Autor: ibsi 15.02.13 - 10:41

    Code kann aber auch kompliziert sein, und deshalb ist es schon sinnvoll mindestens solche Stellen dann ausführlich zu kommentieren.

  3. Re: Guter Code braucht keine Kommentare

    Autor: MaX 15.02.13 - 10:41

    Das seh ich anders. Kommentare nach dem Motto, "Hier mache ich XY" sind nutzlos aber kommentare, in denen steht, warum man etwas gemacht hat sind sehr hilfreich.

  4. Großer Unterschied

    Autor: dabbes 15.02.13 - 10:43

    Kommentare die den Code kommentieren braucht kein Mensch.
    Kommentare die kommentieren was der Code macht aber schon.

  5. Re: Guter Code braucht keine Kommentare

    Autor: Extrabit 15.02.13 - 11:14

    Ein bischen kurz gegriffen. Der Code kann ja sauber sein. Dann erklärt er aber immer noch nicht immer Interdependenzen / komplexe Schnittstellen zwischen verschiedenen Modulen.

  6. Re: Großer Unterschied

    Autor: kopfspringer 15.02.13 - 11:14

    Hat einer von euch eigenlich schonmal mehr als eine Zeile echten Code abgeliefert?

    Ihr Helden!

    Codecomments sind essentiell wichtig!
    Ich rede da von professionellen Softwareprodukten und großen Entwicklungsabteilungen. Es kann dann durchauch passieren, dass ein bestimmter Teil oder Modul der Software jahrelang seinen Dienst tut und dann einem Redesign unterworfen wird oder im Zusammenspiel mit Neuerungen ein Fehler auftritt...

    Eine gewisse sauber gemachte Codekommentierung ist dann mehr als hilfreich, wenn ich nach Jahren an eigenen Code oder Code anderer die vieleicht schon lange das Unternehmen verlassen haben, ran muss.

    Wenn Die Software dann noch komplexe Strukturen wie bspw. ERP Prozesse abbildet, dann ist der Code in der Syntax eventluell noch verständlich, jedoch die Algorithmische bedeutung doch mehr als nebulös... Da sind Kommentare echt angebracht...

  7. "Tod durch Scrollen"

    Autor: renegade334 15.02.13 - 11:25

    Wenn's nach mir geht, tragen überflüssige Kommentare zum Tod durch Scrollen bei. Ich mag's nicht, wenn man für manch so Einiges eine eigene Zeile gönnt für "/**", "*/", "int x=0;" und für "public int getX(){return x;}" gleich 4 Zeilen verschwenden.

    Auch wenn es vor einer extrem langer Zeit an einem Gerät programmiert habe wo man beim Programmieren nur 6 Zeilen Code beim Editieren sieht. Trotzdem kann man mehr sehen, wenn man etwas kompakter schreibt. Ich wäre mehr begeistert, wenn man zum Beispiel sowas schreiben würde anstatt eine ganze Bildschirmhöhe dafür zu brauchen:
    public int getSize(){ return size;}
    public void setSize(String size) this.size=size;}
    public void stopServer() this.server.stop;}
    Haben wir gegenüber der konventionellen Schreibweise schon mal mindestens 6 Zeilen gespart. Kennt jemand schon einen Checkstyle, der mir unnötige zeilen kürzt?
    Für Euch ist das vielleicht noch ungewohnt, aber ich finde es leserlicher, da ich nicht zu stark daran gewöhnt bin, sehr schnell vertikal zu lesen.

    Okay, aber für Matheberechnungen finde ich Kommentare schon sinnvoll, damit ich den Ansatz wenigstens versteher. Und man programmiert wie so oft nicht selten allein ;-)



    2 mal bearbeitet, zuletzt am 15.02.13 11:30 durch renegade334.

  8. Re: "Tod durch Scrollen"

    Autor: BLi8819 15.02.13 - 11:35

    Getter und Setter kommentieren ist auch ganz schön Witzlos ;)
    Die lässt man sich einmal generieren und dann bleiben die ausgeblendet ^^

    Wichtig werden Kommentare bei komplexen Methoden oder mathematischen Funktionen, bei denen Hintergrundwissen Notwendig ist.

  9. Re: "Tod durch Scrollen"

    Autor: renegade334 15.02.13 - 11:42

    BLi8819 schrieb:
    --------------------------------------------------------------------------------
    > Getter und Setter kommentieren ist auch ganz schön Witzlos ;)
    > Die lässt man sich einmal generieren und dann bleiben die ausgeblendet ^^
    Ich find's auch komisch, dass Getter/Setter nie in eine Zeile geschrieben werden bzw. dass meistens 4 Zeilen deswegen in Anspruch genommen wurden ("Signatur", Nutzcode, dann "}" und Zwischenleerzeile). In persönlichen Code packe ich sowas in eine Zeile ohne leeren Zwischenzeilen falls kurz genug (Code-Statements mit Tabs auf eine Ebene gebracht).

  10. Re: Guter Code braucht keine Kommentare

    Autor: bstea 15.02.13 - 11:43

    Dafür ist eine Dokumentation da.
    Sollte das doch einer als Kommentar hinterlassen, würde ich schon seine fachliche Eignung hinterfragen.

    Was ich überhaupt nicht leiden kann ist, wenn die Kommentare zu viel Platz in Anspruch nehmen. Erst letztens hab ich den Code eines Chip8 Emulator eines Freundes refactored. Da wurde jeder Opcodes nochmals erklärt, was den Code unnötig aufgebläht und nichts mit Implementierung zu tun hatte.

    --
    Erst wenn der letzte Baum gefällt, der letzte Fluss gestaut und der letzte Fisch gefangen ist, werdet ihr feststellen, dass man Biber nicht essen kann!

  11. Re: "Tod durch Scrollen"

    Autor: theonlyone 15.02.13 - 11:57

    Programmiert man Test Driven hat man in aller Regel eine gute Dokumentation allein durch die TestAbdeckung.

    Will jemand wissen was eine Funktion macht muss nur der zugehörige Test betrachtet werden, bzw. ausgeführt.

    Parameter ordentlich zu benennen, das sie aussagekräftig sind ist auch etwas das viele nie gelernt habe.

    Da heißen die Paramter dann "x_1_y" und es ist total unklar was das sein soll.

    Grobe Dokumentation sagt einfach so kurz wie möglich was die Funktion machen soll.

    Sind ein paar "hacks" in der Funktion die nicht gewöhnlich sind, werden sie dokumentiert und SOWIESO mit einem entsprechend Zeichen versehen (da man solche hacks immer dokumentieren sollte, wenn möglich entfernen und durch standardisierte Lösungen ersetzen).


    Ein Algorithmus der sehr komplex ist muss entsprechend beschrieben werden, mit Beispielen wenn möglich (daher Test-Driven hat man gleich ein Anwendungsbeispiel).

    Macht man etwas in seinem Code das ohne Kommentar einfach unklar ist, sollte einem klar werden das diese Sache einfach schlecht gelöst ist (auch wenn einem auf Anhieb keine bessere Lösung einfällt, so MUSS diese stelle einfach gekennzeichnet werden).

  12. Re: Guter Code braucht keine Kommentare

    Autor: ruamzuzler 15.02.13 - 12:17

    Sehe ich auch so, vor allem wenn man irgendwelche Workarounds bastelt muss, weil das darunter liegende System buggy ist. Aber das kommt ja eh nieeee vor ...

  13. Re: Guter Code braucht keine Kommentare

    Autor: teenriot 15.02.13 - 13:26

    MaX schrieb:
    --------------------------------------------------------------------------------
    > Das seh ich anders. Kommentare nach dem Motto, "Hier mache ich XY" sind
    > nutzlos

    Ich finde es durchaus sinnvoll innerhalb einer Funktion Codeblöcke durch einzeilige Kurzkommentare abzutrennen um beim späteren Überflug auf Anhieb zu wissen was passiert wenn eine Funktion etliche Zeilen hat.
    Was ich nämlich nicht leiden kann ist die Aufsplittung von Codeblöcken in jeweils eigene Funktionen die dann doch nur einmal im Code aufgerufen werden und nur in einem bestimmten Kontext sinnvoll sind und nicht allgemein funktionieren.

  14. Re: "Tod durch Scrollen"

    Autor: teenriot 15.02.13 - 13:40

    renegade334 schrieb:
    --------------------------------------------------------------------------------
    > Wenn's nach mir geht, tragen überflüssige Kommentare zum Tod durch Scrollen
    > bei. Ich mag's nicht, wenn man für manch so Einiges eine eigene Zeile gönnt
    > für "/**", "*/", "int x=0;" und für "public int getX(){return x;}" gleich
    > 4 Zeilen verschwenden.
    >
    > Auch wenn es vor einer extrem langer Zeit an einem Gerät programmiert habe
    > wo man beim Programmieren nur 6 Zeilen Code beim Editieren sieht. Trotzdem
    > kann man mehr sehen, wenn man etwas kompakter schreibt. Ich wäre mehr
    > begeistert, wenn man zum Beispiel sowas schreiben würde anstatt eine ganze
    > Bildschirmhöhe dafür zu brauchen:
    > public int getSize(){ return size;}
    > public void setSize(String size) this.size=size;}
    > public void stopServer() this.server.stop;}
    > Haben wir gegenüber der konventionellen Schreibweise schon mal mindestens 6
    > Zeilen gespart. Kennt jemand schon einen Checkstyle, der mir unnötige
    > zeilen kürzt?
    > Für Euch ist das vielleicht noch ungewohnt, aber ich finde es leserlicher,
    > da ich nicht zu stark daran gewöhnt bin, sehr schnell vertikal zu lesen.

    Du vermeidest vertikales Scrollen führst damit aber horizontales scrollen ein.
    Denn wenn Methode und Parameter ordentlich benannt sind hat man nicht selten 120 Zeichen oder mehr bei einem simplen setter. Das schlimme ist das der eigentlich relevante Code außerhalb des nicht gescrollten 'Sichtfensters' liegt

    Es ist echt ein Problem das code conventions, die den Zweck haben Code leserlich zu machen bei strikter Anwendung oft das Gegenteil bewirken und sich teilweise widersprechen.
    Ausschließlich durch Regeln zu sauber anzusehenden Code zu kommen funktioniert leider nicht. Man braucht Gefühl für Regelbrüche um wirklich 'ästhetisch' zu werden.

    Beispiel:
    Ich empfinde es als ideal wenn ich meinen Code an keiner Stelle horizontal scrollen muss. Andererseits hasse auch ich die Platzverschwendung durch Boilercode. Und zusätzlich hätte ich gerne fast identitischen Codezeilen in Folge so formatiert das gleiche Parts exakt untereinander stehen.
    Dafür wird man keine einheitlichen regeln aufstellen können. Der Stil muss immer an Ort und stelle entschieden werden.

  15. Re: Großer Unterschied

    Autor: GodsBoss 16.02.13 - 08:38

    > Hat einer von euch eigenlich schonmal mehr als eine Zeile echten Code
    > abgeliefert?

    Ja.

    > Codecomments sind essentiell wichtig!
    > Ich rede da von professionellen Softwareprodukten und großen
    > Entwicklungsabteilungen. Es kann dann durchauch passieren, dass ein
    > bestimmter Teil oder Modul der Software jahrelang seinen Dienst tut und
    > dann einem Redesign unterworfen wird oder im Zusammenspiel mit Neuerungen
    > ein Fehler auftritt...
    >
    > Eine gewisse sauber gemachte Codekommentierung ist dann mehr als hilfreich,
    > wenn ich nach Jahren an eigenen Code oder Code anderer die vieleicht schon
    > lange das Unternehmen verlassen haben, ran muss.

    Noch viel besser helfen da ordentliche, leicht lesbare Unit Tests. Die sind vor allem deswegen besser als Kommentare, weil Kommentare und der Code, z.B. nach Änderungen, divergieren können, aber wenn die Unit Tests nicht mehr zum Code passen, schlagen sie fehl.

    > Wenn Die Software dann noch komplexe Strukturen wie bspw. ERP Prozesse
    > abbildet, dann ist der Code in der Syntax eventluell noch verständlich,
    > jedoch die Algorithmische bedeutung doch mehr als nebulös... Da sind
    > Kommentare echt angebracht...

    Gegen Dokumentation, die die Konzepte erklärt, will ich nichts einwenden, ist aber nicht das, was ich unter „Code Comments“ verstehen würde.

    Reden ist Silber, Schweigen ist Gold, meine Ausführungen sind Platin.

  16. Re: "Tod durch Scrollen"

    Autor: GodsBoss 16.02.13 - 08:55

    > Getter und Setter kommentieren ist auch ganz schön Witzlos ;)
    > Die lässt man sich einmal generieren und dann bleiben die ausgeblendet ^^

    Code-Generierung ist ein deutliches Signal für Mängel in der gewählten Programmiersprache. Ebenso können Getter-Setter-Paare Anzeichen für eine schlechte Struktur sein, wenn derartige Objekte tatsächlich ihre Innereien darbieten, weil das dem Prinzip des Information Hiding widerspricht.

    Reden ist Silber, Schweigen ist Gold, meine Ausführungen sind Platin.

  17. Re: "Tod durch Scrollen"

    Autor: Heinz Müllersen 16.02.13 - 10:29

    renegade334 schrieb:
    --------------------------------------------------------------------------------
    > public int getSize(){ return size;}
    > public void setSize(String size) this.size=size;}
    > public void stopServer() this.server.stop;}

    Hätten Sie mehrere Zeilen genutzt, dann wäre Ihnen beim Schreiben vermutlich aufgefallen, dass sie einige Klammern vergessen haben.

  18. Re: "Tod durch Scrollen"

    Autor: KleinerWolf 16.02.13 - 10:46

    hey Nase, wir haben heutzutage Monitore, die kann man um 90 Grad drehen. Wir arbeiten nicht mehr an 80x25 10" Bernstein Monitoren.

  19. Re: "Tod durch Scrollen"

    Autor: KleinerWolf 16.02.13 - 10:47

    owned :-P

  20. Re: Guter Code braucht keine Kommentare

    Autor: sknoche 16.02.13 - 15:21

    Naja, in dem Moment, in dem sich innerhalb einer Funktion mehrere "Code-Blöcke" befinden, tut diese bereits mehr als sie eigentlich sollte!

  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Anzeige
Stellenmarkt
  1. Wirecard Technologies GmbH, Aschheim bei München
  2. Haufe Akademie GmbH & Co. KG, Freiburg im Breisgau
  3. Robert Bosch GmbH, Stuttgart-Feuerbach
  4. K+S Aktiengesellschaft, Kassel

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Blu-ray-Angebote
  1. 9,99€
  2. (u. a. Interstellar 8,99€, Django Unchained 8,99€, Das Leben des Brian 7,99€)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Deus Ex Mankind Divided im Test: Der Agent aus dem Hardwarelabor
Deus Ex Mankind Divided im Test
Der Agent aus dem Hardwarelabor
  1. Summit Ridge AMDs Zen-Chip ist so schnell wie Intels 1.000-Euro-Core-i7
  2. Doom Denuvo schützt offenbar nicht mehr
  3. Deus Ex angespielt Eine Steuerung für fast jeden Agenten

Avegant Glyph aufgesetzt: Echtes Kopfkino
Avegant Glyph aufgesetzt
Echtes Kopfkino

Next Gen Memory: So soll der Speicher der nahen Zukunft aussehen
Next Gen Memory
So soll der Speicher der nahen Zukunft aussehen
  1. Arbeitsspeicher DDR5 nähert sich langsam der Marktreife
  2. SK Hynix HBM2-Stacks mit 4 GByte ab dem dritten Quartal verfügbar
  3. Arbeitsspeicher Crucial liefert erste NVDIMMs mit DDR4 aus

  1. Medion X5520: Smartphone mit Fingerabdrucksensor und reichlich Speicher
    Medion X5520
    Smartphone mit Fingerabdrucksensor und reichlich Speicher

    Ifa 2016 Viel Speicher für wenig Geld: Medion hat mit dem X5520 ein neues Android-Smartphone mit einer Speicherbestückung wie bei Oberklassegeräten vorgestellt. Außerdem gibt es einen Fingerabdrucksensor.

  2. Smartphones: Google will die Nexus-Linie einstellen
    Smartphones
    Google will die Nexus-Linie einstellen

    In diesem Jahr erscheinen voraussichtlich keine neuen Nexus-Smartphones. Nach einem Bericht wird die Nexus-Modellreihe nicht fortgeführt. Neue Google-Smartphones wird es aber geben - allerdings diesmal mit Nexus-untypischen Anpassungen.

  3. Yuneec Breeze 4K: Die 500-Euro-Drohne für Selfies
    Yuneec Breeze 4K
    Die 500-Euro-Drohne für Selfies

    Früher wurden Quadcopter auch als Luftnägel bezeichnet, weil sie dank GPS und ausgefeilter Steuerung an Ort und Stelle schweben können. Die Eigenschaft macht sich auch die Drohne Yuneec Breeze 4K zunutze, um Selfies des Besitzers zu machen. Aus der Luft.


  1. 10:00

  2. 09:30

  3. 09:20

  4. 09:00

  5. 08:39

  6. 07:47

  7. 07:34

  8. 07:23