Was meine ich mit "gibt es nicht" - je nach Level der anderen mitarbeitenden (zukünftigen) Entwickler - sowohl generell, als auch Sprach- bzw. Projekt-spezifisch, gibt es in komplexen Systemen nichts, wo nicht ein wenig Dokumentation angebracht ist.
Solche Dokumentation zum "Großen Ganzen" findet sich aber eher nicht innerhalb einer bestimmten Sourcecode Datei.
Sei es eine Beschreibung des Typen, der Methodenparameter, auftretender Exceptions, oder - innerhalb der Methode - die Logik. Letzteres ist das, was oft am wenigsten nötig ist, aber Schnittstellen und Methoden sollten meiner Erfahrung nach immer eine Beschreibung mit sich bringen.
Kann man sich das meiste von sparen, indem man die Dinge entsprechend benennt - siehe Beispiel von Jeff im Artikel.
Es reicht allerdings nicht nur eine gute Benamung sondern auch das Einhalten, bestimmter Prinzipien, z.B. des
Single Level of Abstraction - womit man aus dokumentier/kommentierwürdigen if/while/for- Code Klumpen einfach verständliche und selbsterklärende Subroutinen formen kann.
Übrigens habe ich nicht gesagt, dass man nix dokumentieren/kommentieren sollte, sondern, dass ich deiner Aussage, dass jeglicher Code, sei er noch so kurz, Kommentare aufweisen muss, nicht zustimme - bzw nachfragte, um welche Kommentare es sich dort denn handeln solle. Dass du nun Beispiele nennst, wo Dokumentation und Kommentare notwendig sind, beantwortet diese Frage nicht.
