Gibt es empirische Studien zu den Auswirkungen des Kommentierens von Quellcode auf Softwarequalität, Wartbarkeit und Entwicklerproduktivität? [geschlossen]

Ich bin ein Verfechter des Kommentierens des Quellcodes und des Dokumentierens von Softwareprodukten. Es ist meine persönliche Erfahrung und Beobachtung, dass die Arbeit an Quellcode, der streng kommentiert wird, mir auf unterschiedliche Weise geholfen hat, wenn ich Software erweitern oder warten musste.

Es gibt jedoch ein anderes Lager, das besagt, dass das Kommentieren letztendlich wertlos oder sein Wert fraglich ist. Zahlreiche Befürworter der Codierung ohne Kommentar argumentieren, dass:

• Wenn ein Code gut geschrieben ist, ist er selbsterklärend und muss daher nicht kommentiert werden
• Wenn ein Code nicht selbsterklärend ist, überarbeiten Sie ihn und machen Sie ihn selbsterklärend, sodass keine Kommentare erforderlich sind
• Ihre Testsuite ist Ihre Live-Dokumentation
• Mit der Zeit werden Code und Kommentare nicht mehr synchronisiert und es kommt zu einer weiteren Quelle von Kopfschmerzen
• Laut Agile ist Arbeitscode wichtiger als viele Dokumentationen, sodass wir das Schreiben von Kommentaren ignorieren können

Für mich ist das nur ein Dogma. Wiederum war meine persönliche Beobachtung, dass Software, die von Teams intelligenter und erfahrener Entwickler geschrieben wurde, letztendlich eine beträchtliche Menge an Code enthält, die nicht selbsterklärend ist.

Auch hier zeigen die Java-API, die Cocoa-API, die Android-API usw., dass es möglich ist, Qualitätsdokumentation zu schreiben und zu verwalten.

Nach alledem enden Gespräche über Vor- und Nachteile der Dokumentation und Kommentare zum Quellcode, die auf persönlichen Überzeugungen beruhen, normalerweise nicht gut und führen zu keinen zufriedenstellenden Schlussfolgerungen.

Als solches suche ich nach wissenschaftlichen Arbeiten und empirischen Studien über die Auswirkungen der Softwaredokumentation, insbesondere des Kommentierens von Quellcode, auf ihre Qualität und Wartbarkeit sowie auf ihre Auswirkungen auf die Teamproduktivität.

Sind Sie auf solche Artikel gestoßen und was war das Ergebnis davon, wenn überhaupt?

In "Die Auswirkung von Modularisierung und Kommentaren auf das Programmverständnis" (1981) stellten Woodfield, Dunsmore und Shen fest, dass "Probanden, deren Programme Kommentare enthielten, mehr Fragen beantworten konnten als solche ohne Kommentare".

In "Lernen einer Metrik für die Lesbarkeit von Code" (2010) stellten Raymond PL Buse und Westley Weimer jedoch fest, dass Kommentare nur einen begrenzten Einfluss auf die Lesbarkeit und Qualität haben:

Aus der Zusammenfassung:

Wir erstellen ein automatisiertes Lesbarkeitsmaß und ... zeigen, dass diese Metrik stark mit drei Maßstäben für die Softwarequalität korreliert: Codeänderungen, automatisierte Fehlerberichte und Fehlerprotokollmeldungen ... Unsere Daten legen nahe, dass Kommentare an sich weniger wichtig sind als einfache Leerzeilen zu lokalen Beurteilungen der Lesbarkeit.

Ab Seite 12:

Wir haben festgestellt, dass Kommentare nur mäßig gut mit dem Begriff der Lesbarkeit unserer Kommentatoren korrelieren (33% relative Leistung). Eine Schlussfolgerung könnte sein, dass Kommentare zwar die Lesbarkeit verbessern können, jedoch normalerweise in Codesegmenten verwendet werden, die anfangs weniger lesbar waren: Der Kommentar und der nicht lesbare Code gleichen sich effektiv aus. Der Nettoeffekt scheint zu sein, dass Kommentare nicht immer an und für sich auf eine hohe oder niedrige Lesbarkeit hinweisen.

Denken Sie daran, dass die Befürworter von "Codieren ohne Kommentieren" nicht sagen, dass Code ohne Kommentare besser ist als Code mit Kommentaren. Sie argumentieren, dass ein bestimmter Codestil ohne Kommentare - einer, der Code in Methoden mit selbstbeschreibenden Namen extrahiert , einer, der erklärende Variablen einführt , einer, der eine gute Testsuite hat - besser ist als Code, der diese Dinge nicht tut hat aber Kommentare. Dies könnte die Anwendbarkeit aller durchgeführten Studien erschweren.