Hallo zusammen,
Ich führe im Rahmen meiner Masterarbeit ein Forschungsexperiment zum Thema Codelesbarkeit durch und brauche hierfür eure Unterstützung!
Das Experiment besteht aus 9 kleinen Java-Aufgaben und sollte nicht länger als eine Stunde dauern.
Ihr könnt das Experiment aber einfach online durchführen:
[ul]
[li] dev-ovgu.de
[/li][/ul]
Vielen Dank schon mal an alle Teilnehmenden!
P.S.: Weiterleiten erwünscht 
Bin mal auf die Auswertung gespannt. Codelesbarkeit hat viele Facetten. Die abschließende Frage kam etwas überraschend. Hoffentlich ist das jetzt kein “Spoiler”, aber …
EDIT: Hab’s mal rausgenommen, kann ja in 3 Wochen wieder rein.
Erstmal vielen Dank, dass du dir die Zeit genommen hast 
Die Auswertung (+Zusammenfassung) werde ich definitiv veröffentlichen. Das Thema ist sehr beliebt, und deswegen auch (oder vor allem?) außerhalb der Uni interessant.
Die Diskussion würde ich aber gerne erst nach Abschluss des Experiments fortsetzen (~3 Wochen), um die Ergebnisse auf keine Weise zu verfälschen.
Warum spielt es eigentlich für eine Rolle ob man in Informatik seinen Abschluss hat? Besonderer Hintergrund?
Nicht jeder Informatiker kann programmieren, hat geschweige denn jemals in seinem Leben Quellcode gesehen, das ist keine Zwangsbedingung in dem Beruf. Auf der anderen Seite gibt es genügend andere Studien und Berufsgänge die Programmieren als festen Bestandteil oder zumindest in gleicher Form vorraussetzen. Software Engineering mal als Beispiel, bzw. heutztage hat Softwareentwicklung in allen Studiengängen Platz gefunden, für den BWLer wie für den Maschinenbauer.
Habe etwas an der Frage gehapert ob ich einen Informatik Abschluss habe.
Habe mich gefragt ob die Frage nicht eventuell darauf abzielt ob man generell einen Abschluss hat der Programmieren beinhaltet.
Oder ist das so beabsichtigt?
[QUOTE=TMII]Habe etwas an der Frage gehapert ob ich einen Informatik Abschluss habe.
Habe mich gefragt ob die Frage nicht eventuell darauf abzielt ob man generell einen Abschluss hat der Programmieren beinhaltet.
Oder ist das so beabsichtigt?[/QUOTE]
Die Frage ist als “Abschluss im Bereich Informatik” formuliert, also auch “Software Engineering” oder gar “Computermathematik”. Es soll aber absichtlich mehr als “ich hatte mal eine Java-Vorlesung mitgemacht”-BWLer beinhalten.
Es ist aber auch nicht schlimm, wenn sich jemand nicht sicher ist und die “falsche” Antwort auswählt.
Wie gesagt - ich würde die Absicht dieser Fragen erst nach der Studie erläutern.
Ich habe auch an der Umfrage teilgenommen und bin auf die Auswertung auch sehr gespannt. Jetzt habe ich einige Punkte im Kopf, über die man sehr gut diskutieren könnte, aber ich möchte dir natürlich nicht deine Ergebnisse beeinflussen.
An einigen Stellen habe ich in die Lösungen Inlinekommentare eingefügt 
um Erläuterungen hinzuzufügen. Also keine Erläuterungen zum Quellcode, sondern zur Antwort.
@darekkay
Da hab ich die Frage wohl missverstanden
@cmrudolph
Du glaubst jemand wertet den Code am Ende aus? Dachte eigentlich von Anfang an, dass das direkt in die Tonne geht und am Ende die eigentlichen Fragen zur Vorgehensweise kommen.
Ganz im Gegenteil - ich muss die Lösungen unter anderem auf Richtigkeit überprüfen.
Also Ich hatte mal keinerlei Hilfsmittel und die Methode qux() hat mich verwirrt, aber vielleicht sollte das so sien. Jedenfalls mal teilgenommen.
Edit: Der Compiler wird’s schon durchlaufen.
Hmm, es ist gerade Montag früh 02:13 - und ich hab 08:00 Frühschicht - ich werds mir also heute nach Feierabend mal geben …
… aber bei “ovgu” musste ich schmunzeln da ich schon vor dem Klick auf den Link wusste wofür das Kürzel steht - Grüße aus Diesdorf =P
Um nicht durch einen spoiler-Block andere zu beeinflussen Kommentar als PN …
“BUMP”… Fertig?
Spätestens nächste Woche werde ich das Experiment beenden, dann kann die Diskussion beginnen 
Nebenbei schreibe ich schon fleißig an meiner Abschlussarbeit.
Ich bin von der regen Teilnahme überrascht. 156 Personen haben das Experiment bis zum Ende durchgeführt und etwa 220 Personen haben immerhin die ersten 3 Aufgaben gelöst.
davon kannst Du einmal abziehen, ich hatte keinen Bock die Fragen auf dem Tablet zu beantworten und bin dann nach oben, an den Desktop, gewandert
So, das Experiment ist nun abgeschlossen. Vielen herzlichen Dank an alle, die teilgenommen haben!
Also, worum geht’s genau? Die meisten haben sicherlich mitbekommen, dass es um Kommentare geht. Genauer: um den Einfluss von Kommentaren auf die Codelesbarkeit.
Nun könnte man schnell zu Uncle Bob rüber schauen und sämtliche Best Practices aufzählen. Ordentliche Bezeichnernamen statt Kommentaren, Kommentare nur wenn absolut notwendig und wenn sie das WARUM statt dem WAS erklären, Javadoc-Kommentare bei Libraries Pflicht.
Mein Experiment wurde im Rahmen meiner Masterarbeit durchgeführt, also muss ich das ganze auch wissenschaftlich angehen. Bisherige Arbeiten überschneiden sich an einigen Stellen mit den Best Practices, an anderen nicht.
Ich untersuche zusätzlich die Unterschiede zwischen Kommentararten (Inline, Javadoc, [keine]) und die Aufgaben sind in drei Bereiche aufgeteilt: Code verwenden, Fehler beheben und Code erweitern.
Nun zu den größten „Kritikpunkten“ der Studie - ja, die Bezeichnernamen sind anonymisiert (foo, bar, number). Und ja, viele Kommentare wären nicht nötig gewesen, wenn die Bezeichnernamen vernünftig gewählt worden wären. Und ja, der Code ist oft unnötig kompliziert geschrieben. Es fehle am Bezug zum „echten“ Code.
All das war logischerweise gewollt. Es war ein experimenteller Versuch, um nur den Einfluss der Kommentare zu untersuchen. Der Code musste einfach genug sein, um 9 Aufgaben mit etwa einer Stunde Bearbeitungszeit zu erhalten - aber schwer genug, damit überhaupt Unterschiede festgestellt werden können.
Noch ein paar Worte zum Experimentaufbau: Es gibt 9 Aufgaben (3 Aufgaben pro Bereich, s.o.), die jeweils (1) unkommentiert sind (2) nur Inline-Kommentare enthalten und (3) nur Javadoc-Kommentare enthalten. Was die Teilnehmer nicht wussten - sie wurden auf 3 Gruppen verteilt, die alle die selben 9 Aufgaben hatten, aber eben unterschiedlich kommentiert. Es hatte trotzdem jeder Teilnehmer mit jeder Kommentarart zu tun gehabt. Nun kann ich also die Unterschiede zwischen den Gruppen untersuchen. Das heißt, sowohl die Richtigkeit der Ergebnisse (das ist der nun müheselige Teil), als auch die Schnelligkeit der Beantwortung (ja, bei jeder Frage lief ein Timer mit).
Wozu brauchte ich noch die Info, ob man einen „Abschluss im Bereich Informatik“ habe? Gemeinsam mit der Selbsteinschätzung und der Anzahl der Jahre in der Programmierung werden diese Angaben dafür genutzt, die Erfahrung der Teilnehmer einzuschätzen, um nur etwa gleich erfahrene Entwickler miteinander verglichen.
So, die Diskussion kann nun beginnen
Das wird bei meinen Antworten dazu führen, dass die Ergebnisse etwas verfälscht sind. Ich habe bei 2 oder 3 Aufgaben längere Pausen gemacht (einmal sogar über eine Stunde - das sollte man also sehen), weil was anderes dazwischen kam.
Ich erinnere mich an die Aufgaben jetzt nicht mehr so gut. Bei einer war aber ein „erwartetes“ Ergebnis angegeben, welches von dem, was ich erwartet habe, abwich. Das habe ich als Inlinekommentar auch in der Antwort dokumentiert. Habe ich dort einen Denkfehler, oder war das Absicht?
Ein Timer lief mit? Das wusste ich nicht, kein Hinweis, keine Einblendung. Ich dachte, nur Start und Stopp. Ich hab mich aber trotzdem beeilt. [emoji5] Irgendwie bekam ich bei mir die schwerste Aufgabe ganz ohne Kommentare. Gut, gebe ich auch noch meine Meinung ab: Oft (nicht immer [emoji20] ) ist der Sourcec. ein relevanter Kommentar.
Kein Sorge, sehr lange Pausen fallen tatsächlich auf, und werden bei der Auswertung nicht berücksichtigt.
Das war vermutlich die Transpositionsaufgabe. Der Code basierte auf einer Methode aus der Apache Commons Library, sorgte aber tatsächlich für etwas Verwirrung bei den Teilnehmern. Die Aufgaben werden aber ohnehin einzeln ausgewertet, also ist das nicht gaaanz so schlimm.
Es gab nur den Hinweis: „bitte möglichst am Stück lösen“. Ich wollte die Teilnehmer mit dem Hinweis auf einen Timer nicht unter künstlichen Druck setzen, was die Ergebnisse eventuell verfälscht hätte.
Das war die etwas größere Aufgabe zum Schluss - und die Gruppe, die bei dieser Aufgabe gar keine Kommentare hatte, sollte deutlich schlechter abschneiden. Das wird sich zeigen
Guck ich mir nachher an.
Aber Code wird deutlich lesbarer, wenn man else und catch unter die Klammer schreibt. Nicht dahinter. Dieser Sun-Stil ist Mist. Und wird nicht besser, dass er sich in der Java-Community via Immitation verbreitet hat.
Hier noch das, was ich vor >1 Monat noch geschrieben und dann wieder rauseditiert hatte (jetzt können die Flamewars ja ruhig ein bißchen angeheizt werden :D)
Ich frage mich manchmal, ob Leute “Kommentare” schreiben, um behaupten zu können, sie hätten Kommentare geschrieben, ohne zu lügen. Gerade habe ich mal (abgesehen von einigen Namen unveränderten) Code aus aus meiner IDE hier kopiert:
// label
setLabel(node, resultNode);
// transform
Matrix matrix = setTransform(node, instance, resultNode, scale, globalTransform);
// bounding box
setBoundingBox(node, instance, resultNode, scale, matrix);
// metadata
processMetadata(node, resultNode);
(Das muss man wohl nicht weiter kommentieren…)
Ich gebe ja zu, dass ich ein Kommentar-Nazi bin, und für ALLES (ALLES) JavaDoc-Kommentare erstelle. Natürlich kommt da dann manchmal “Noise” raus, den man zumindest hinterfragen, und meinetwegen auch als “schlecht” bezeichnen kann…
class Person
{
/**
* The last name of this person
*/
private String lastName;
/**
* Returns the last name of this person
*
* @return The last name of this person
*/
public String getLastName()
{
return lastName;
}
/**
* Set the last name of this person
*
* @param lastName The last name of this person
*/
public void setLastName(String lastName)
{
this.lastName = lastName;
}
}
statt
class Person
{
private String lastName;
public String getLastName()
{
return lastName;
}
public void setLastName(String lastName)
{
this.lastName = lastName;
}
}
Aber wenn mir mal langweilig ist, oder ich müde bin und nicht über was “richtiges” nachdenken will, dann schreibe ich halt noch
/**
* Returns the last name of this person. This will
* never be <code>null</code>, and will never be
* an empty string. Oder was auch immer.
*
* @return The last name of this person
*/
dazu.
Diese JavaDoc/Interface-Kommentare sind aber IMHO eine komplett andere Kategorie (und IMHO komplett unabhängig) von “inline-Kommentaren”. Darüber, ob letztere “gut” oder “schlecht” sind, wurde schon ausführlich diskutiert. Manche bezeichnen die als “Code Smell”. Ich denke, wenn man darüber reden will, muss man ausdifferenzieren, zwischen Kommentaren, die das “WAS” beschreiben, und Kommentaren, die das “WARUM” beschreiben. Letztere wird man wohl kaum in Frage stellen können - willkürliches Beispiel aus etwas, was ich kürzlich gemacht habe:
// Some glTF files have single values instead of arrays,
// so accept this for compatibility reasons
objectMapper.configure(
DeserializationFeature.ACCEPT_SINGLE_VALUE_AS_ARRAY, true);
Gegen Kommentare, die das “WAS” beschrieben, im Sinne von Blöcken wie
// Set stuff up
int i = init();
setUp(i);
start();
// Do this and that
float that = doThat(i);
performAnd(this, that);
// Clean up
delete(this);
clear(that);
shutDown();
wird oft argumentiert, dass man das in Methoden auslagern sollte. Aber ich finde, es gibt auch Argumente, die dagegen sprechen, 5 Zeilen Code in eine Methode zu packen, wenn die Methode privat wäre, nur an einer Stelle verwendet würde, und ggf. mehrere Parameter übergeben bekommen müßte (und… wie das bei Methoden eben so ist: Auch einen JavaDoc-Kommentar bräuchte :D)