Diskussion:Programmierstil

Kodierrichtlinie

Ist mit "Programmierstil" hier "Kodierrichtlinie" gemeint? Ein "Programmierstil" hat für mich einen individuellen Charakter, während eine "Kodierrichtlinie" eine Art von Regelwerk darstellt.
Die Aussage "Als Programmierstil [...] bezeichnet man einen Satz von Regeln." finde ich persönlich als falsch. (nicht signierter Beitrag von 80.152.5.244 (Diskussion | Beiträge) 15:00, 19. Mär. 2010 (CET))

Ich seh' da keinen Unterschied, ob das ein Satz von Regeln meiner Firma oder in meinem Kopf sind. Läuft beides darauf hinaus, dass der Quellcode nachher eine bestimmte Form hat. --arilou (Diskussion) 13:08, 1. Apr. 2012 (CEST)

Ich sehe da schon einen Unterschied! Siehe Stil.

Dort steht: Das Wort Stil bezeichnet eine charakteristisch ausgeprägte Art der Ausführung menschlicher Tätigkeiten.

Und weiter: Die „charakteristische Ausprägung“ bezieht sich auf Ähnlichkeit bezüglich formaler Merkmale (nicht auf die Gleichheit der Form wie bei Standardisierungsprozessen)

Das Einhalten von Namenskonventionen und Formatierungsregeln würde ich deshalb nicht als (Programmier-)Stil bezeichnen.

Ein Stil geht weit über das Einhalten von Regeln hinaus und hat nicht unwesentliche kreative Anteile.

Einen Stil kann man beobachten, eine Richtlinie kann man vorgeben.

Gudi (Diskussion) 14:21, 16. Aug. 2012 (CEST)

Da gebe ich dir recht, und präzisiere meine Aussage:

Ob "Kodierrichtlinien" zur Quelltextformatierung von der Firma vorgegeben sind, oder ich gleichlautende Quelltextformatierungsregeln im Hirn habe, läuft auf dieselbe Formatierung hinaus.

So meinte ich meine Antwort. Ansonsten: siehe unten.

--arilou (Diskussion) 16:25, 16. Aug. 2012 (CEST)

Ich stelle auch fest, dass die Definition (in der Einleitung) unkorrekt ist: Richtlinie, Konvention etc. und Stil liegen zwar begrifflich eng beiieinander (Stil = das WIE im Tun, gemäß einer Richtlinie). Wären das identische Begriffe, dann wäre ja z.B. der Ausdruck 'Styleguide' ein 'weißer Schimmel'. Eine Enzyklopädie jedenfalls sollte derartige Wortverwandtschaften nicht zu einem (1) 'Begriffskonglomerat' verwässern. Den Zusammenhang kann und soll man aber beschreiben, z.B. auch unter 'Siehe auch'. --VÖRBY (Diskussion) 12:51, 21. Jan. 2013 (CET); zusätzliches Argument: --VÖRBY (Diskussion) 16:10, 21. Jan. 2013 (CET)

Begrifflich sind zum hier diskutierten Unterschied (Stil/Konvention ...) sogar 3 Dinge zu unterscheiden:

• Die Erscheinungsform (hier: von Code) - eigentliche die Definition von 'Stil' (s.a. Diskussion hier)
• Die Vorschrift, die Details dazu regelt: Konvention, Richtlinie etc.
• Das Tun, das sich daran orientiert.

--VÖRBY (Diskussion) 10:07, 23. Jan. 2013 (CET)

Zeilenlänge

Das Java-Beispiel ist eines, das sich in der Tat relativ schlecht umbrechen läßt, weil einfach viele Konstruktor-Aufrufe mit meist nur einem Argument geschachtelt werden. Für diesen entarteten (aber zugegebenermaßen häufigen) Fall ist mir keine verbreitete Konvention bekannt. Es gibt aber Beispiele, die sehr viel mehr von Zeilenumbrüchen profitieren; z. B. wenn jeweils mehr als ein Argument übergeben wird.

Beispiel:

   public ModelAndView handleList(HttpServletRequest request,
                                  HttpServletResponse response)
   throws ServletException {
       //...
   }

Eclipse z. B. kann ein solches Format automatisch erzeugen, wenn die Zeilenlänge ansonsten den eingestellten Maximalwert überschreiten würde. Was es AFAIK nicht kann, ist eine einzige lange Zeile "on the fly" in vergleichbarer Weise umzubrechen; in diesem Fall wird allenfalls an Wortgrenzen umgebrochen, oder der hintere Teil rutscht (irgendwann ganz sicher) nach rechts aus dem sichtbaren Bereich. Der Platz auf dem Monitor ist m. E. zu schade, um ihn für überlange Zeilen zu verpulvern.

Es mag ja sein, daß viele Zeilen "trotz ihrer Länge leicht verständlich" sind; bei sinnvollem Umbruch lassen sie sich aber praktisch "auf einen Blick" erfassen, sind also "noch viel leichter" verständlich. Der Verzicht auf sinnvolle Umbrüche ist m. E. eher der Faulheit geschuldet als einer tatsächlich verbesserten Lesbarkeit (und die Faulheit ist kein Argument mehr, wenn die Umbrüche von der IDE geleistet werden).

"In einem guten Editor kann man eine umbrochene Zeile deutlich von einer neuen Zeile unterscheiden." − Das ist zwar meistens richtig (und hängt manchmal von den getätigten Einstellungen ab), ist aber dann ohne Belang, wenn der Zeilenumbruch an sich nicht signifikant ist, sich für den Compiler also als stinknormaler Whitespace verhält. Das Auge hat dennoch mehr Arbeit damit, die nur an Wortgrenzen umgebrochene Token-Suppe aufzulösen.

"In einem normalen Java-Programm wäre die Zeile bei einer Einrückungstiefe von vier Leerzeichen pro Block mindestens 140 Zeichen lang." – In ihrem jetzigen Zustand ist die Zeile 129 Zeichen lang. Wie stellt sich denn der Autor dieses Satzes einen Umbruch der Zeile vor? Meinem Eclipse fällt hierzu nichts ein; manuell würde ich es vielleicht so machen (leider immer noch 108 Zeichen):

out = new PrintWriter(new OutputStreamWriter(new BufferedWriter(new FileOutputStream(new File(baseDir,
                                                                                              "test.txt"))),
                                             "utf-8"));

oder auch jeweils die geöffneten Klammern umbrechen, um noch etwas Breite zu sparen.

Aber entartetete Beispiele (wie sie von Java leider begünstigt werden) sind kein Grund, generell darauf zu verzichten, den Sourcecode lesbar zu formatieren.

Die Empfehlung

Mit der vorhandenen Empfehlung − "Man sollte im Zweifelsfall immer prüfen, ob das Umbrechen der Zeile die Lesbarkeit tatsächlich erhöht. Tut sie das nicht, sollte man lieber nicht umbrechen." − bin ich nicht einverstanden. Eine nach semantischen Kriterien umgebrochene Anweisung ist immer lesbarer als wenn sie sich auf eine Breite von über 100 Zeichen erstreckt; eine nicht sinnvoll unterteilbare Anweisung leidet nicht, wenn man sie einfach an Wortgrenzen umbricht, wobei z. B. der Ausdruck in einer Zuweisung stets auf der rechten Seite des Gleichheitszeichens bleibt. Wenn Tools dabei helfen können, sollte man sie auch benutzen.

Meine Empfehlung wäre:

• man bleibe mit der Zeilenlänge soweit möglich innerhalb des Druckbereichs (üblicherweise maximal 80 Zeichen in einem monospace-Font) und dessen, was sich am Bildschirm ohne Kopfbewegung auf einen Blick erfassen läßt
• wenn Tools beim Umbrechen helfen können, sollte man sie benutzen (und spart sich damit eine große Anzahl bisher empfohlener Einzelfallprüfungen)
• ansonsten ist der Aufwand gegen den Nutzen abzuwägen; 200 Zeichen lange Zeilen sind aber eine ergonomische Katastrophe, die glücklicherweise immer vermeidbar ist.

--Tobias 16:40, 13. Nov. 2006 (CET)

Update für eine lesbar formatierte, automatisch erzeugbare Version der Java-Bandwurmzeile:

out = new PrintWriter(
          new OutputStreamWriter(
              new BufferedWriter(
                  new FileOutputStream(
                      new File(baseDir,
                               "test.txt"))),
              "utf-8"));

Hier stehen Argumente untereinander, die zum selben Konstruktoraufruf gehören, und die Klassennamen stehen dicht beieinander. IDEs und bestimmte Editoren können zwar beim Bearbeiten die jeweils zugehörige Klammer hervorheben; dies geschieht aber nicht beim Ausdruck. Bei dieser Formatierung bleibt die Zuordnung auch beim Ausdruck sichtbar; bei Einrückung des ganzen Beispiels um zwei Ebenen (Methode einer Klasse) bleibt es sogar dann noch innerhalb des sicheren druckbaren Bereichs von 80 Zeichen, wenn pro Schachtelung um zwei Ebenen (à 4 Leerzeichen) eingerückt wird statt nur um eine.

Ein weiterer Aspekt ist, daß Vergleichsprogramme oft zeilenweise arbeiten. Wird z.B. im obigen Aufruf ein Klassenname ausgetauscht (z.B. durch eine lokale erweiterte Version), steht diese Änderung klar ersichtlich auf einer eigenen geänderten Zeile; im anderen Fall (eine einzige lange Zeile) würde z. B. diff eine sehr lange entfernte und eine sehr lange hinzugefügte Zeile anzeigen, und man müßte schon genau hinschauen, wo der signifikante Unterschied zwischen beiden ist. --Tobias 12:54, 10. Jun. 2008 (CEST)

---

Meine Empfehlung wäre, keine Empfehlungen in Wikipedia zu formulieren! Ob der Autor mit dem einen oder anderen Programmierstil auf Kriegsfuß steht oder nicht, oder hier und da eine Zeile privat mal nicht umbricht, die nach irgendeinem Programmierstil umgebrochen gehört, tut doch nichts zur Sache. Wikipedia ist doch keine Tippsammlung! Bitte Abschnitt löschen. --Any nick 03:06, 30. Jan. 2008 (CET)

Dann sollten wir die Empfehlung löschen, im Zweifelsfall nicht umzubrechen; die ist nicht von mir (ich halte sie ja auch für falsch), ich habe demnach mit den Empfehlungen nicht angefangen...

Im übrigen stehe ich nicht mit irgendetwas „auf Kriegsfuß“, sondern habe sachliche Argumente vorgebracht.

Die starke Neigung eingefleischter Java-Programmierer zu überlangen Zeilen hat m. E. zwei Ursachen:

• Die stark zum Schwafeln neigende Sprache Java (man betrachte sich nur das Beispiel) ist überhaupt nur praktikabel, weil es mächtige IDEs gibt, die den Sourcecode halbautomatisch generieren. Um nicht jede Menge Handarbeit verrichten zu müssen, gewöhnt man sich an einen Stil, den diese Tools ohne besondere Einstellungen eben erzeugen (wobei man im Fall von Eclipse z.B. die zu verwendenden Konventionen ohne weiteres ebenso wie die Quelltexte versionieren und projektweit vorgeben könnte) bzw. den aufgrund seiner Primitivität sicher jedes beliebige Tool erzeugen kann. Und da man sich nunmal unter Schmerzen gewöhnt hat, wischt man jedes Argument beiseite, das darauf hindeuten könnte, daß das keine gute Idee war („warum sollten andere weniger leiden als ich?“).
• Damit die Einrückungen auf jedem Entwicklerrechner vernünftig aussehen, muß man einen stringenten Einrückungsstil durchhalten und i.d.R. auf die Verwendung von Tabulatoren verzichten (im Beispiel ist „out = “ 6 Zeichen breit, was nicht von der Einrückungskonvention abhängt, sondern von der Länge des Variablennamens; zusätzlich zu Tabulatoren würden jedenfalls Leerzeichen gebraucht, was bei uneinheitlich definierten Tabulatoren die meisten Tools überfordern dürfte). Editoren wie Vim z. B. können das auch (set expandtab softtabstop=4 sorgt dafür, daß die Tab-Taste Leerzeichen erzeugt, die beim Löschen wie Tabs behandelt werden); in mit Eclipse entwickelten Java-Projekten gibt es aber in der Regel keine versionierte Konfiguration, die die Sache sauber erledigen würde (obwohl das möglich wäre). --Tobias 12:54, 10. Jun. 2008 (CEST)

Viel zu langer Artikeltext

Ich denk, mich laust der Affe! Was soll soviel Detail in einem Artikel, der 'Progrmmierstil' heißt? Da genügt doch die Aussage, dass sich das Umbrechen von Quellcode-Text, also dessen Zeilenlänge in erster Linie an den Gegebenheiten der Programmiersprache orientieren sollte und entsprechend organisationsintern geregelt sein kann. Soll hier ein Java- oder sonstwie heißender Kurs gehalten werden? Das Lemma sollte doch wohl neutral sein. Ich schlage vor, hier gründlich zu optimieren / reduzieren und werde das je nach Feedback demnächst tun.--VÖRBY 17:40, 17. Mär. 2011 (CET)

Bislang kein Feedback; deshalb habe ich den folgenden Text entfernt: --VÖRBY 10:36, 27. Mär. 2011 (CEST)

---

Beispiele:

Die Zeile

public ModelAndView handleList(HttpServletRequest request, HttpServletResponse response) throws ServletException {
    //...
}

lässt sich nach semantischen Kriterien automatisch wie folgt formatieren (von Eclipse erzeugt):

public ModelAndView handleList(HttpServletRequest request,
                               HttpServletResponse response)
throws ServletException {
    //...
}

Dabei stehen die formalen Parameter der Funktion untereinander, und das wichtige Schlüsselwort „throws“ steht in einer neuen Zeile.

Komplizierter wird es bei folgender Anweisung:

out = new PrintWriter(new OutputStreamWriter(new BufferedWriter(new FileOutputStream(new File(baseDir, "test.txt"))), "utf-8"));

Realistischerweise um zwei Ebenen à 4 Leerzeichen eingerückt (Klasse und Methode) und auf einem Drucker mit 80 Zeichen/Zeile ausgedruckt, ergibt sich z. B.:

        out = new PrintWriter(new OutputStreamWriter(new BufferedWriter(new
FileOutputStream(new File(baseDir, "test.txt"))), "utf-8"));

Wird nach denselben Kriterien umgebrochen wie im ersten Beispiel, ergibt sich:

out = new PrintWriter(new OutputStreamWriter(new BufferedWriter(new FileOutputStream(new File(baseDir,
                                                                                              "test.txt"))),
                                             "utf-8"));

und bei Ausdruck auf demselben Drucker z. B.:

        out = new PrintWriter(new OutputStreamWriter(new BufferedWriter(new
FileOutputStream(new File(baseDir,
 
                      "test.txt"))),
                                                     "utf-8"));

Wenn sich also die maximale Zeilenbreite nicht am druckbaren Bereich orientiert, kann das Umbrechen dieser Zeile die Lesbarkeit im Ausdruck eher erschweren als befördern. Wird die Zeile jedoch wie folgt umgebrochen:

out = new PrintWriter(
          new OutputStreamWriter(
              new BufferedWriter(
                  new FileOutputStream(
                      new File(baseDir,
                               "test.txt"))),
              "utf-8")); // zu OutputStreamWriter

dann bleibt die Lesbarkeit auch im Ausdruck erhalten.

---

Überarbeiten

Die Einleitung reduziert den Begriff auf einen eher unwesentlichen Teilaspekt. --Wladislaw 20:16, 19. Mär. 2008 (CET)

Verstehe ich jetzt nicht. Programmierstil bezieht sich fast nur auf Formate. Vielleicht noch Namen von Variablen und Funktionen aber das geht schon Richtung Architekturrichtlinie (bei Schnittstellenrelevanz auf jeden Fall). --Arcudaki 10:22, 20. Mär. 2008 (CET)

Dann lies dir den Artikel bitte ganz durch. Steht alles drin. --Wladislaw 19:58, 20. Mär. 2008 (CET)

erledigt. --Gms 19:26, 14. Sep. 2008 (CEST)

Setzen von Klammern

Bei uns in der Abteilung gibt es zwei Glaubensgrundsätze bzgl. der Klammersetzung bei Blöcken a) öffnende { direkt hinter dem Schlüsselwort b) öffnende { in neuer Zeile unter dem Schlüsselwort (entsprechend eingerückt)

gerhört meiner Meinung auch zum Programmierstil, steht hier aber nicht drin

Habe den Satz entsprechend geändert und Einrückung durch Anordnung ersetzt. --Thornard, ^Diskussion, 18:35, 26. Aug. 2008 (CEST)

Vor ein paar Jahren habe ich es endlich mal erlebt, dass eine Firma, keine Regel zur Klammerposition aufgestellt hat. Was für ein Segen. Keine dieser verfluchten Streitereien um dieses unwichtige Thema. Jeder konnte einfach so programmieren, wie er es gewohnt war. Und kam es zu Problemen? Natürlich nicht. Es hat weder die Lesbarkeit verschlechtert noch zu unnötigen Fehlern geführt. Wer also gerade Programmierrichtlinien für ein Entwicklungsteam aufstellen muss, dem kann ich nur empfehlen: Überlege Dir gut welche Regeln Du wirklich brauchst. Es bringt nichts, anderen Deine Vorlieben anderen aufzuzwingen, wenn damit keine Verbesserung erreicht wird. --Stefan (nicht signierter Beitrag von 84.187.189.213 (Diskussion) 19:14, 27. Apr. 2012 (CEST))

Setzen von Klammern ist deutlich überbewertet. Es gibt 100te andere wesentlich wichtigere Punkte, in den meisten Projekten wird aber für die Entscheidung bezüglich Klammernsetzen bereits soviel Energie verschwendet, dass die anderen Punkte gar nicht angegangen werden. Gott sei Dank gibt es Entwicklungsumgebungen wie Eclipse, wo bei jedem Save automatisch der Stil bis ins kleinste Detail korrigiert wird. 2 Stunden murrende Junior-Entwickler, dafür den Rest des Projektes keine Diskussionen mehr. --Sebastian.Dietrich ✉ 09:35, 28. Apr. 2012 (CEST)

Zu pauschal

Aussagen, dass heute "ausreichend Speicherplatz für den Code zur Verfügung steht" sind zu pauschal. Wenn man an Mikro-Controller etc. denkt ist es grob falsch. Klingt wieder so als wenn der Artikel von jemandem verfasstwurde der nur PCs etc. im Blick hat. (nicht signierter Beitrag von 94.220.178.2 (Diskussion) 14:17, 31. Mär. 2012 (CEST))

Mikrocontroller u.ä. werden i.A. per Crosscompiler von einem PC aus programmiert. Auf dem PC ist genug Speicherplatz, um am Sourcecode nicht einzelne Bytes sparen zu müssen. Und das ist pauschal so richtig, oder?

Allenfalls wenn die Symbolnamen auch im Compilat bleiben, das dann auf den Mikrocontroller gespielt wird, könnte es evtl. sinnvoll sein, selbige etwas kürzer zu halten.

--arilou (Diskussion) 13:03, 1. Apr. 2012 (CEST)

Programmierstil vs. Kodierrichtlinie und Quelltextformatierung

Der Artikel (und auch sein Inhaltsverzeichnis sowie die Weblinks) reduziert Programmierstil im Wesentlichen auf Quelltextformatierung. Andere Aspekte wie objektorientiertes Paradigma, Design Patterns, Modularität, etc. werden als "Programmierstil im weiteren Sinne" abgetan. Genau letztere sind jedoch meines Erachtens wichtiger Bestandteil eines Programmierstils. Zugegebenermaßen kann man diese Dinge nicht mit klaren eindeutigen Regeln beschreiben. Deshalb frage ich mich, wieso es nicht einen Artikel "Quelltextformatierung" gibt, der dann auch in starkem Zusammenhang mit Kodierrichtlinen stehen kann. Ein Artikel "Programmierstil" sollte hingegen auf Dinge fokusieren wie

• Einsatz von statischen Methoden vs. Instanzmethoden
• Polymorphie
• Kapselung
• Umgang mit Vererbung und Interfaces
• Vermeidung von Redundanz
• Anwendung von Prinzipien Objektorientierten Designs
• etc.

Programmierstil als die Art wie ein Entwickler bzw. ein Entwicklungsteam Quelltext schreibt umfasst außerdem auch Themen wie testgetriebene Entwicklung und Refactoring.

Und zu guter letzt spielt natürlich auch die Quelltextformatierung eine nicht ganz unwichtige Rolle.

Gudi (Diskussion) 13:56, 16. Aug. 2012 (CEST)

Ganz deiner Meinung. --arilou (Diskussion) 16:27, 16. Aug. 2012 (CEST)

Stimme auch zu. Die Diskussion hier zeigt, dass die möglichen Inhalte schwer von anderen Begriffen abgrenzbar sind - und noch schwerer 'belegbar'. Ein Ergänzen und Zusammenführen wäre hierzu eine Kompromisslösung. Siehe auch Diskussion zu Code-Qualität.--VÖRBY (Diskussion) 10:02, 22. Jan. 2013 (CET)

Vorhandensein von Kommentaren = guter Programmierstil?

Das steht im Artikel: "Darüber hinaus ist die Abwesenheit von Kommentaren im Quellcode ein Zeichen für einen schlechten Programmierstil. Eine programmierende Person muss immer davon ausgehen, dass ihr Code auch von anderen gelesen und verstanden werden muss; hierzu sind Kommentare unerlässlich." Das mag vor 20 Jahren gestimmt haben. Spätestens seit der "Clean Code"-Idee sollte Code so formuliert werden, dass er möglichst ohne Kommentare gut lesbar ist, indem der Code "sprechend" formuliert wird. (nicht signierter Beitrag von 46.59.200.5 (Diskussion) 20:04, 13. Apr. 2023 (CEST))

Stimmt und entsprechend geändert. --Sebastian.Dietrich  ✉  20:57, 13. Apr. 2023 (CEST)

Sieht jetzt so aus, als ob man heute (im Gegensatz zu früher - zweimal explizit erwähnt) überhaupt keine Kommentare mehr bräuchte. Das mag für "sprechend" verfasste einzelne Kommandos/Befehle gelten (Kommentare wären Redundanz). Aber: Kann der Code etwa eine kurze Erläuterung zu einer bestimmten, evtl. nicht ganz trivialen Codefolge/Funktion (etwa ein 'Warum') - zum besseren Verständnis - wirklich ersetzen? Ich denke schon, dass Kommentare (wo sinnvoll) nach wie vor Zeichen guten Stils sein können. Auch sollten wir hier nicht 'schwarz-weiß' argumentieren: Total ohne vs. übermäßig ausführlich. --VÖRBY (Diskussion) 10:14, 14. Apr. 2023 (CEST)

Können wir gerne anders formulieren. Aber zumindest lt. Refactoring und Clean Code gelten Codekommentare schon generell als Smell (siehe Code-Smell#Verbreitete Smells). Selbstverständlich bin ich der Meinung, dass das "warum nicht anders implementiert" (d.h. selten) ein Kommentar wert ist, aber idealerweise nicht im Quellcode (sondern darüber). Aber die Literatur ist da schon meines Wissens nach eindeutig. --Sebastian.Dietrich  ✉  12:59, 14. Apr. 2023 (CEST)

Die Aussagen in Code-Smell können m.E. nicht als Forderung zum Verzicht auf jede Form von Kommentar interpretiert werden: Dort wird lediglich HÄUFIG Begleitform von schlecchtem Code erwähnt - und dass Kommentare ... ein HINWEIS auf schlechten Code sein KÖNNEN; beides nicht quantifiziert, aber ganz klar nicht IMMER bedeutend. Außerdem: Sicher findet sich der Aspekt 'Kommentare' nicht zufällig ganz am Ende der Beispiele-Liste; wie formuliert Fowler wohl im Original?

Also: Man darf "das Kind nicht mit dem Bad ausschütten". Der eindeutige Beleg von ICP-Uni-Stuttgart sollte das klar genug zeigen, auch unabhängig von Programmiersprachen.

Vielleicht sollte man den ganzen Kommentarabschnitt unter 'Umstrittene Elemente' behandeln: Dort wäre der geeignete Platz für die Aussage sparsame Kommentare je nach Progr-Sprache. Und: Ein Hinweis, dass 'sprechende Namen' (als Alternative) das Codeverständnis zT besser geeignet sind, würde dort auch gut passen. --VÖRBY (Diskussion) 18:13, 14. Apr. 2023 (CEST)

Ja bin auch dafür das unter umstrittene Elemente zu verschieben. Hab jetzt nachgelesen, sowohl Fowler als auch Martin betrachten Kommentare differenziert. Robert C. Martin hat z.B. (Clean Code S53 ff) den Kommentaren ein ganzes Kapitel gewidmet und einige Typen für gute und viele für schlechte Kommentare beschrieben. --Sebastian.Dietrich  ✉  18:35, 14. Apr. 2023 (CEST)

Eine beispielhafte Quelle sowohl für (in anderen Sprachen, hier C) evtl. überflüssige als auch für sinnvoll gesetzte Kommentare ist z.B.: https://www2.icp.uni-stuttgart.de/~hilfer/lehre/100-online/skriptum/html_book00/node19.html

Zitat von dort: "... Deshalb ist es ebenso wichtig zu lernen, wie man ein Programm kommentiert wie das Programmieren selbst."

Die Quelle könnte als 'Einzelnachweis' verwendet werden. --VÖRBY (Diskussion) 12:52, 14. Apr. 2023 (CEST)

Das Beispiel ist mMn katastrophal. Ok stammt aus 2002 aber schon damals wusste man wie das besser geht. Das Skriptum sagt 1) über Code-Kommentare bis auf ein paar Allgemeinsätze nix aust 2) kapriziert es sich auf größtenteils sinnlose Infos im Fileheader und enthält 3) beinahe 100% schlechte Kommentare im Code. z.B.:

// Schleife von t=0 bis t=t_max

for( int i=0; i<=t_max/dt; i++ )

das Kommentar ist nicht nur sinnlos (weil man das aus dem Code ohnedies rauslesen kann), sondern auch noch falsch (weil nicht bis t_max sondern bis t_max/dt iteriert wird. --Sebastian.Dietrich  ✉  18:52, 14. Apr. 2023 (CEST)

Ja, zur 'Schleife' ist das dort ein Beispiel für 'schlechte' Kommentare, andererseits gibt es auch Empfehlungen für zweckmäßige Kommentare.

Schon der bisherige Einzelnachweis zu Java (siehe 'oracle.com') weist auf den potentiellen Zusammenhang ('sometimes') zwischen Comment-Frequency und Codequality hin - UND gibt Empfehlungen für zweckmäßige Comments. Ein JA oder NEIN zu Kommentaren ist damit nicht möglich. Willst Du, auch gem. Deiner o.g. Recherchen, entsprechend anpassen? --VÖRBY (Diskussion) 22:42, 14. Apr. 2023 (CEST)

Ich habs jetzt mal so aus dem Buch nach bestem Wissen übersetzt - ist sicherlich noch verbesserungswürdig, aber auf jeden Fall schon mal korrekter als das Ursprüngliche... --Sebastian.Dietrich  ✉  17:08, 15. Apr. 2023 (CEST)

in Benutzer:VÖRBY/temp habe ich einiges zur Einleitung (Kommentare betreffend) eingestellt; der Text sollte nicht direkt mit der 'früher'-Aussage beginnen. Ggf. direkt dort aktualisieren und dann übernehmen. Danke. --VÖRBY (Diskussion) 19:06, 17. Apr. 2023 (CEST)

Ich würde das 1:1 so übernehmen bis auf den ersten Satz (das Zitat aus dem Vorlesungsscript), da ich vermeiden möchte, dass dem Link auch jemand folgt (weil das meiste andere, was dort steht wie gesagt ziemlich problematisch ist). mMn passt das Zitat auch nicht gut zu Kommentar, sondern besser zu sprechendem Code - d.h. ich würde es einfach weglassen.

Alternativ dazu gibt es andere, bessere Zitate zu Kommentaren. z.B. "Code is like humor. When you have to explain it, it's bad" (Cory House), "The proper use of comments is to compensate for our failure to express ourself in code." (Robert C. Martin), "Code never lies, comments sometimes do." (Ron Jeffries) --Sebastian.Dietrich  ✉  08:29, 18. Apr. 2023 (CEST)

Done. Habe festgestellt, dass es noch einen Hauptartikel dazu gibt; vlt. würden die Detail-Listen (gut/schlecht) von R.C.Martin dort besser passen. --VÖRBY (Diskussion) 11:16, 18. Apr. 2023 (CEST)

Defekter Weblink

Dieser Baustein verhindert die automatische Archivierung dieses Abschnitts und seiner Unterabschnitte.

Der folgende Weblink wurde von einem Bot („GiftBot“) als nicht erreichbar erkannt.
Ausführliche Erläuterungen und Hilfe zur korrekten Behebung dieses Fehlers finden sich auf Wikipedia:Defekte Weblinks. Ist ein von einem Bot als defekt gemeldeter externer Link doch erreichbar, dann bitte berichten – wie auch sonstige Probleme.

• http://www.hyfisch.de/didaktik/Forschung/INFOS95.pdf
  • Vielleicht ist eine archivierte Version geeignet: archive.org
  • Netzwerk-Fehler (7) andere Artikel, gleiche Domainhttp://giftbot.dwl.invalid/http://www.hyfisch.de/didaktik/Forschung/INFOS95.pdf
  • Artikel mit gleicher URL: Pascal (Programmiersprache) (aktuell)

– GiftBot (Diskussion) 15:35, 20. Dez. 2015 (CET)

Dieser Link ist (bei mir) ok. Aber der Link zu Uni Karlsruhe (Java Conventions) war kaputt; ersetzt. Link für VB ebenfalls defekt; gslöscht. --VÖRBY (Diskussion) 12:56, 21. Dez. 2015 (CET)

Quelle defekt

https://www.uwe-sauerland.de/ scheint es nicht mehr zu geben. --217.150.152.145 08:55, 24. Jul. 2023 (CEST)