Umfrage: Java-Experiment

[OT][quote=ThomasT]Aber Code wird deutlich lesbarer, wenn man else und catch unter die Klammer schreibt.[/quote]Na wenn Du meinst…

[quote=ThomasT;136359]Dieser Sun-Stil ist Mist.[/quote]Mir gefällt er und ins besondere die Klammersetzung und zwar aus 2 Gründen:
[ol]
[li]Der Code wird nicht durch die (fast) leere Zeile “zerrissen”
[/li][li]Zwischen Klammer und catch darf nichts stehen. Wenn mann weis, dass man an jedem Zeilenende einfach Enter drücken und weitertippen kann ist das IMHO recht hilfreich.
[/li][/ol]
[/OT]
bye
TT

Tabs sind besser, als Leerzeichen. :popcorn:

Und ich bin der Ruler. :popcorn:

[OT]Ich bin der Typ mit den Spaces… :D[/OT]

Mal erlich, das mit dem newline nach } usw. hab ich am Anfang auch mal gemacht. Damit wäre ThomasT also Anfänger.

Aaaber findet ihr es auch alle besser, wenn ein Tab aus 8 Spaces besteht?

https://www.youtube.com/watch?v=K5WW7JOBSjg

Auf einen zumindest ansatzweise sinnvoll-inhaltlichen Flamewar hatte ich schon gehofft.
(Ich meine, dass Spaces besser sind als Tabs ist ja nichts, worüber man lange diskutieren müßte)

Sorry, konnt mich nicht zurueckhalten :smiley:

Zum Thema:

Ich mag Kommentare eigentlich nicht besonders. Weder lesen noch schreiben. Liegt daran, dass ich inzwischen schon soooooooo (viel zu) oft gesehen hab, dass ein Kommentar absolut gar nix mit dem Code dazu zu tun hat, weil das beim letzten Refactoring vergessen wurde.

Auch bei APIs uebrigens, wenn diese halbwegs gut durchdacht ist, braucht man keine Kommentare (siehe Beispiel oben ThisGetterGetsTheName).

Die einzige relevante und wahre Wirklichkeit ist der Code. Alles andre ist unvollstaendig, falsch oder lenkt ab.

Absolut hilfreich find ich dagegen (gute!) Tests und Beispielcode (bzw Tutorials).

Ich bin auch nicht so der Kommentierer. Bei Public-APIs finde ich Javadocs aber sehr wichtig. Die sind in der IDE gut erreichbar und helfen bei der Auswahl der richtigen Methode.
Wenn es dann ans Detail geht, lese ich mich häufig auch noch einmal kurz durch den Code.
Inlinekommentare halte ich meistens für überflüssig. In den meisten Fällen, wenn sie mir bei Fremdcode begegnen sind sie entweder falsch eingesetzt, sodass sie einen Block einer Methode beschreiben, der besser in einer eigenen Methode landen sollte, oder sie beschreiben Implementierungsdetails / -entscheidungen. Dort wiederum finde ich Inlinekommentare angemessen.

*keuch * keuch hust keuch röchel keuch Bin ich zu spät zum Tabs vs Spaces Religionskrieg? Ohhhh… mist! Würde gerne mal eine IDE sehen die einfach auf Beide-Methoden verzichtet.

Inlinekommentare halte ich auch meistens für nutzlos. Manchmal gliedern sie eine Methode auch in schöne abgetrennte Unterabschnitte, was den Code übersichtlicher macht.
Methodenkommentare aber sind unabdingbar, ich möchte nicht den Sourcecode lesen müssen um zu verstehen was die Methode macht, wenn man das überhaupt kann.
Das es genügend Verrückte bei Java gibt die dann lieber solche Methodennamen fabrizieren
“getNameAndSetChangeFlagToTrueWhichTriggersFramebufferToRefillData();”
den man dann jedesmal erneut eintippen darf, hab ich auch schon gemerkt.
Das hat zwar den Vorteil das man genau sieht was die Methoden genau bewirken (bis zu einer gewissen Tiefe zumindest) aber die Methoden sind schwerer zu merken, es dauert ewig bis man mal eine eingetippt hat und es braucht länger den Code zu lesen.
Dann merke ich mir lieber kurz und knapp “getName();” und lese EINMAL die JavaDoc und behalte die Informationen im Hinterkopf.

Bei Methoden die man nicht so oft verwendet werden, wird erstere Variante natürlich wieder attraktiver.

[quote=TMII]Das es genügend Verrückte bei Java gibt die dann lieber solche Methodennamen fabrizieren
[langerMethodenName]
den man dann jedesmal erneut eintippen darf,[/quote]Dann machst Du was falsch!

Ich schreibe MethodenNamen nur ein einziges mal, nämlich dann wenn die Methode angelegt wird. Sonst nutze ich die Autocompleetion der IDE.

bye
TT

Gestern/heute war/ist Flamewar Tag. Aber das ist kein Grund, hier abzuröcheln. Wo ist denn dein benehmen?

BTT: Es kommt drauf an, wie und wo man etwas eingibt. Schreibe ich selber was im Forum, wähle ich 2-3 Leerzeichen, da Tabs Steuerelemente in ALLEN Browsern anspringt. In der IDE (hey, welche findet ihr eigentlich besser? :smiley: ) übernimmt das Gott-sei-Dank (hey, welche Götter findet ihr eigentlich besser? :smiley: ) für mich.

Lange Methodennamen: Wenn nix anderes vereinbart…

Ich habs schon via PN geschrieben - nun mal öffentlich: Entweder habe ich die Aufgabe nicht verstanden oder du bist irgendwie komplett am Ziel vorbeigeschossen.
Im ursprünglichen Post war mal die Rede von „Thema Codelesbarkeit“
Als ich den „Test“ gemacht hab dachte ich mir nur so: WTF?=! Was hat „Algorithmen nachbasteln“ um irgendwann nach Mitternacht mit Codelesbarkeit zu tun?
Jetzt kommt als Antwort: Ging um Kommentare. Ach und um fehlerhaften Code fixen - und noch was erweitern - und dann noch rückwärts-Trapdoors für irgendwelche Algos basteln …

Sorry, ich hab jetzt nicht alle Antworten gelesen - und um erlich zu sein auch nicht die Antwort auf die PN - aber kanns mir bitte noch mal wer erklären worum genau es jetzt eigentlich ging?
Ich mein: Die Coding-Aufgaben wo es um die Algorithmen ging hab ich schlicht mit „skipped“ beantwortet da ich erlich gesagt schlicht 1) nicht wirklich verstanden hab worum es ging und was es mit dem im Post genannten Thema zu tun haben soll 2) kein Bock drauf hatte mir irgendwelche Algorithmen zu geben und dann für vorgegeben Code für die eine Richtung mir noch was für die Umkehrfunktion zu überlegen.

Code-Lesbarkeit sind für mich Dinge wie schon angesprochen: Tabs vs Spaces (zum Link: ich fand das Ende witzig - tried to take 8 steps at once - LAWLed), open bracket same or next line, spaces after commas (gerade bei Parametern) und so weiter. Ich hab irgendwo das Umleitungsschild „Kommentare ->“ verpasst … und daher auch scheinbar kein geeigneter Testkandidat gewesen.
Jeder hat seinen eigenen Stil: Manche halten sich wortwörtlich an die conventions, andere sehen es eher als „Hinweise“ (ja, die Anspielung auf den Spruch aus Fluch der Karibik ist gewollt) - bei einigen gibt es den Streitpunkt „ISomeInterface“ - was teils als „C-Stil“ verspottet wird (ich muss sagen: ich finds auch irgendwie - naja - da hält sich halt mal wieder eins dieser minecraft-modder-script-kiddies nicht an etablierte java-standards und hats aus irgend einem noch sehr viel mieseren tutorial übernommen) - und wieder andere werfen alles über den haufen und versuchen irgendwie auf biegen und brechen eine goto-semantik nachbasteln zu wollen.

Sicher - wenn die eigentliche Frage hinter dem Test war wie sich Kommentare auf den Lesefluss auswirken - hätte man erstens dann die Frage auch bitte mal genau so stellen können/sollen (bin erlich mal auf den Titel deiner Arbeit gespannt) und zweitens demnach dann dieses ganze Survey irgendwie komplett anders aufziehen können.

Ist meine Ansicht - aber wie gesagt: vielleicht hab ich auch einfach nur die Aufgabe nicht verstanden - aber es hatte und nach dem was ich jetzt gelesen habe hat für mich nichts mehr dem im OP genannten „Thema Codelesbarkeit“ zu tun - bzw. ist die eigentliche Motivation für mich nicht deutlich geworden.

shots fired - just my 2ct

Ich finde den Ansatz recht gelungen, insbesondere, dass die Kommentare bei den Probanden unterschiedlich waren.
Zwischen Codeverständnis und Codelesbarkeit dürfte es eine starke Korrelation geben. Zwischen Codeverständnis und richtiger Antwort ebenfalls. Zwischen guter Lesbarkeit und schnellem Verständnis gibt es auch einen Zusammenhang.
Das zusammengenommen kann man aus der Antwortdauer und der Korrektheit der Antwort Rückschlüsse auf die Lesbarkeit ziehen.
Um den Faktor Schwierigkeitsgrad der Aufgabe bei der Antwortzeiten zu entfernen, gab es unterschiedliche Kommentare für die Probanden.
Ich denke, das war die Intention, @darekkay ?
Alles in Allem meiner Meinung nach ein sehr wissenschaftlicher Ansatz.

Zu glauben, dass Codelesbarkeit nur etwas mit Codekonventionen zu tun hat, ist naiv. Auch Kommentare tragen zum Codeverständnis in gewissen Situationen bei. Darüber hinaus ist der grundsätzliche Aufbau des Quellcodes (Zuständigkeit von Klassen, Granularität etc.) viel wichtiger.
Ansonsten empfehle ich noch die Lektüre von “Clean Code”, einem Standardwerk zu sauberer Programmierung. Auch wenn die Regeln dort teilweise extrem sind, gibt es ein gutes Gefühl für guten (= lesbaren) Code.

Also mir hat der Ansatz der Umfrage, das Verständnis durch Änderungen am Code zu belegen und die dabei benötigte Zeit zu messen gut gefallen.

Was mir nicht gefallen hat ist, dass der Code selbst bewusst kryptisch gehalten wurde. Dadurch war die Bedeutung der Kommentare für das Verständnis unrealistisch hoch.

Viel Interessanter wäre IMHO gewesen, “clean Code” zu nehmen und dann zu ermitteln, welcher Typ Kommentar zur Verbesserung des Verständnisses führt.

bye
TT

Vielen Dank für euer Feedback! :slight_smile:

[QUOTE=Sen-Mithrarin]Sorry, ich hab jetzt nicht alle Antworten gelesen - und um erlich zu sein auch nicht die Antwort auf die PN
aber kanns mir bitte noch mal wer erklären worum genau es jetzt eigentlich ging?[/QUOTE]

Sorry, hab mir den Rest von deinem Text nicht durchgelesen - kannst du es bitte noch einmal erklären? :rolleyes:

[QUOTE=cmrudolph;136572]Um den Faktor Schwierigkeitsgrad der Aufgabe bei der Antwortzeiten zu entfernen, gab es unterschiedliche Kommentare für die Probanden.
Ich denke, das war die Intention, @darekkay ?[/QUOTE]

Nicht ganz - ich kann die Aufgaben miteinander gar nicht vergleichen (ist Aufgabe 1 doppelt so schwer, wie Aufgabe 2?). Ich untersuche die Unterschiede pro Aufgabe, also heißt es am Ende sowas wie: „bei Aufgabe 1 gibt es einen signifikanten Unterschied in der Bearbeitungszeit zwischen keinen Kommentaren und Inline-Kommentaren“ etc. Daher auch die Einteilung in Use-Cases (vielleicht sind die Unterschiede nur beim Erweitern des Codes signifikant?).

[QUOTE=Timothy_Truckle;136573]Was mir nicht gefallen hat ist, dass der Code selbst bewusst kryptisch gehalten wurde. Dadurch war die Bedeutung der Kommentare für das Verständnis unrealistisch hoch.
Viel Interessanter wäre IMHO gewesen, „clean Code“ zu nehmen und dann zu ermitteln, welcher Typ Kommentar zur Verbesserung des Verständnisses führt.[/QUOTE]

Das ist richtig, aber drei Punkte sprechen für mich dagegen:
(1.) Ich untersuche nur den Einfluss der Kommentare - der Einfluss der Bezeichnernamen ist ein Störfaktor, den ich bewusst rausgenommen habe. Das hat eindeutig eine Auswirkung auf die Interpretation der Ergebnisse, und das bleibt nicht unerwähnt („Bedeutung der Kommentare unrealistisch hoch“).
(2.) Wir alle wissen was Clean Code ist, und wir alle haben mit Code gearbeitet, der diese Normen nicht einhält. Also völlig unrealistisch ist es dann vielleicht ja doch nicht :wink:
(3.) Ich musste bei 9 Aufgaben diese relativ einfach halten, damit die Teilnehmer nicht einen halben Tag für das Experiment opfern müssen. Würde ich Clean Code verwenden, wären die Kommentare bei diesen einfachen Beispielen größtenteils überflüssig, und deren Einfluss wegen (2.) eventuell auch „unrealistisch niedrig“.

TL;DR: Es ist „nur“ eine Masterarbeit. Ich kann ohnehin nicht mehr, als Anzeichen für eine starke Korrelation finden, die in zukünftigen Arbeiten näher untersucht werden müsste. Schlüsse, wie „also deswegen sollte man immer Kommentare verwenden“, wären naiv. Die bisherigen Arbeiten zeigen, wie schwer dieses Problem realistisch und gleichzeitig wissenschaftlich zu erfassen ist (auch wenn es für einige mit ein paar Conventions à la „Tabs vs. Spaces“ erledigt zu sein scheint).

Es gibt aber auch noch weitere Erkenntnisse, die nicht zum Hauptthema der Studie gehören. Etwa: werden Kommentare bei der Aufgabenbearbeitung ebenfalls angepasst oder hinzugefügt? Anzunehmen wäre etwa, dass bereits kommentierter Code eher zu Anpassungen der Kommentare führt.

Hmm… irgendwie denke ich dass du mit das Ergebnis wenn nicht gar verfaelscht zumindest beeinflusst hast, zugunsten von Kommentaren.
Die ganze Idee von vermeiden/reduzieren von Kommentaren liegt zum Grossenteil darin, sprechende Bezeichner zu waehlen (kurze Methoden geben einem mehr Gelegenheit Bezeichner zu waehlen und damit den Code sich selber Dokumentiren zu lassen).

„Unverstaendlicher Code ist unverstaendlich, dann sind Kommentare besser als nix“
vs.
„Its a waste of time to document bad code“

Ist das nicht einfach nur eine selbsterfuellende Prophezeiung?

Habe ich so in dieser Konstellation noch nicht oft gesehen, und schon gar nicht konsistent.
Wenn man schon schlechte Bezeichner waehlt, ist IMHO das Interesse an verstaendlichem Code gering, (Inline) Kommentare dienen dann eher dazu das schlechte Gewissen zu beruhigen, nicht um „Gute Arbeit zu leisten“.

„Naming is hard“ :wink:
Code schreiben der fuers erste funktioniert und meist nur noch vom Compiler verstanden wird ist einfach.

Eine kleine Anekdote:
Ich hab am Donnerstag mit der Authorin eines (intern verwendeten) Maven Plugins den Code refactored und erweitert, nachdem sie das letzte mal vor 8 Monaten daran gearbeitet hatte…
Die Namen waren oft durch Maven Interna vorgegeben (aehm… nicht immer ganz Intuitiv), vor allem Ihre Unit Tests haben deutlich zum Verstaendniss beigetragen und gleichzeitig Fehler in den neuen Erweiterungen aufgezeigt die wir machten.
Wenn man mal „warmgelaufen“ ist und denselben Code fuer Tage/Wochen/Monate bearbeitet wird vieles selbstverstaendlich.

Das denke ich auch. Und insbesondere, wenn die Unterschiede pro Aufgabe verglichen werden:

Dann hättest du dort vielleicht zur Hälfte Beispiele mit sauberen Bezeichnern einbauen können. Das Ergebnis wäre wahrscheinlich gewesen, dass bei den „sauberen“ Beispielen die Kommentare so gut wie keine Rolle mehr spielen.

Darüber hinaus ist es natürlich bei so einer kleinen (wobei für eine Masterarbeit schon recht große) Stichprobe schwierig, eine Signifikanz festzustellen, wenn die Gruppe auch noch gedrittelt ist. Zudem werden auch viele „ungültige“ Antworten dabei sein, die nicht berücksichtigungsfähig sind.

Nichtsdestotrotz bin ich gespannt auf die Auswertung :slight_smile:

Was ich bereits geschrieben habe :wink:

Ich sag’s ja - es ist eben nicht völlig realitätsfern, dass Clean Code Regeln absichtlich oder unabsichtlich gebrochen werden. Das wird für meine Arbeit angenommen, also etwa: „Wenn keine sprechenden Namen gewählt werden, welchen Einfluss haben dann Kommentare auf die Quellcodelesbarkeit?“.

Außerdem reicht selbstdokumentierender Code nicht aus - das sagt selbst Uncle Bob. Wir können mit der Wahl der Bezeichner zwar das WAS, aber nicht das WIESO beschreiben. Hierfür werden nach wie vor Kommentare gebraucht. Leider ist es nicht gerade einfach, ein WIESO bei kleinen Codeschnipseln ohne jeglichen Context einzubauen, daher entsprechend mein Experimentaufbau.

Das liefe aber entweder auf 18 Aufgaben hinaus, oder ich müsste die Einteilung in Use-Cases (verwenden, erweitern, Fehler beheben) aufgeben (was nicht zwingend schlimm wäre). Das Ziel war, dass jede Person jede Kommentarart bei jedem Use-Case bekommt, daher die 9 Aufgaben.

Außerdem, wenn die Aufgaben nicht verlässlich miteinander vergleichbar sind, bringt es nichts, „Aufgabe 1 - Clean Code + Kommentare“ mit Aufgabe 2 - „Kein Clean Code + Kommentare“ zu vergleichen. Wenn ich bei A1 60sek brauche und bei A2 ebenfalls, was heißt das jetzt genau? Wie stelle ich sicher, dass A1 und A2 völlig gleich schwer zu lösen sind, um diesen Faktor rauszunehmen?
Die letzte Überlegung ist übrigens der Grund, warum ich das Ganze „per Aufgabe“ untersuche.

Schnittstellen Beschreibung in Form von JavaDoc sind nicht dasselbe wie Inline Kommentare.
Inline Kommentare haben ihren Wert wenn immer etwas obskures, nicht leicht ersichtliches passiert/passieren soll, Ziel sollte es sein das zu reduzieren falls moeglich.