“When you feel the need to write a comment, first try to refactor the code so that any comment becomes superfluous.” —Martin Fowler via @CodeWisdom
Das würde ich noch stärker formulieren:
*“When you
feel the need towrite a comment,first try torefactor the codeso that any comment becomes superf”
Denn selbst sprechender Code ist nicht selbstsprechend. Den Kalauer konnte ich mir nicht verkneifen. Aber im Ernst, auch nachvollziehbarer Code wird duch angemessene Kommentare nur noch besser verständlich und überhaupt erst relevant. Weil selbstsprechender Code ein Mythos ist − Eric Holscher (Mitgründer von https://readthedocs.org/)
Trotzdem sind die Momente, die man mit dem Dokumentieren von Code verbringt, ausgezeichnete Auslöser für Refactoring-Maßnahmen. Denn dann begibt man sich in einen besonderen Zustand der Klarheit mit einem geschärften Blick für das große Ganze und ist sensibilisiert für zu komplex geratene Bereiche der aktuellen Implementierung. Wenn ein Code-Fragment unangemessen erklärungsbedürftig ist, dann sollte man es refactoren, sodass es sich auf möglichst nachvollziehbare und prägnante Art erklären lässt. Und, was auch immer das Fragment tut, es muss dokumentiert werden, denn aus Sicht des Lesers existiert ein undokumentiertes Feature nicht. Diese Schlussfolgerung habe ich im Zitat von Fowler vermisst, sie entstammt dem Documentation Driven Development.