Aber wenn du schon ein Beispiel lieferst, will ich es auch nutzen. Denn es unterstreicht meine Aussage von oben. Wenn ein Kommentar nötig ist, bedeutet das in 98,57% aller Fälle, dass entweder der Name falsch ist oder die Methode tut zu viel/das Falsche und sollte aufgeteilt werden bzw. etwas anderes tun. Sei mir nicht böse, wenn ich dein Beispiel jetzt total zerpflücke:
Nein, böse bin ich nicht, aber das war nur ein Beispiel, dass ich auf die Schnelle rausgesucht habe.
Ich hatte eine Funktion gesucht, die nicht zu viel Kommentar / Dokumentation hat.
Diese Funktion ist Teil einer Bibliothek, die schon seit mehr als 15 Jahren in Benutzung ist. Sie wird von ca. 40 Entwicklern in unzähligen Projekten verwendet.
Es traut sich einfach niemand so alte und häufig benutze Funktionen "anzufassen".
Aus diesem Grund wurde sie vor ein paar Jahren wenigstens dokumentiert
Ich glaube es gibt sogar eine Funktion
DisableRecursive(Form.Control);
, welche die alte aufruft
In deinen Ausführungen gebe ich dir größtenteils (ich bin kein Fan von sehr langen Namen)
Recht.
Der Entwickler der Funktion würde das heute wahrscheinlich auch anders machen.
Trotzdem würde ich auch bei einer eindeutig benamten Funktion, mit eindeutig benamten Parametern, eine Dokumentation erwarten.
Auch wenn in der Dokumentation "nur" in Prosa das steht, was man beim Namen der Funktion erwarten würde.
Ich bin auch Fan von Änderungshistorien.
z.B: In der Funktion hat sich ab 01.01.2013 folgendes Verhalten geändert: ...
Oder auch der Autor und das Erstellungsdatum einer Funktion.
Diese Informationen bekommt man zwar auch z.B. über ein Blame in git, aber solche Dinge gehören für mich einfach in eine Dokumentation. (Zumindest bei APIs)