Nico Probst hat geschrieben:Ein Kollege hat mir noch von einem interessanten Konzept erzählt, er meinte jemand der seinen Code, nicht seine Interfaces, kommentiert hat schlechten Code geschrieben. ... Wenn ein Code kommentiert werden muss, hätte man ihn umschreiben oder in eine Methode auslagern können, wodurch er an sich klarer wird.
Das ist durchweg interessant aber schlichtweg falsch :twisted:
Wenn man in größeren, kommerziellen Softwareprojekten arbeitet trifft man durchaus auf Stellen in Implementierungen die erklärungsbedürftig sind. Und erschreckenderweise sind das
eben nicht große, langwierige Implementierungen, sondern Ein- oder Zweizeiler deren Notwendigkeit sich eben nicht durch den Algorithmus selbst ergibt. Vielmehr ist das was ich jetzt mal Framework nennen möchte der Grund dafür, dass der eine oder andere Aufruf sein muss der States hier oder da setzen muss damit irgendetwas das tun kann was es tun soll.
Hier mag man argumentieren, dass dann etwas am Framework falsch ist oder sich vom Design her zumindest in Teilen selbst überlebt hat. Im Elfenbeinturm ist das dann absolut korrekt, aber in der Realität eines Softwareentwicklers würde der Umbau eines solchen Frameworks locker mal 4 bis 8 Wochen 2 - 4 Arbeitskräfte binden und den Rest des Teams gleichzeitg hart ausbremsen.
Von daher weigere ich mich Code zu peeren dem an solchen Einzeilern der Kommentar fehlt und bin jedem Peer dafür dankbar wenn er mich auf fehlenden Kommentar bei so etwas hinweist :)
@Topic
Doxygen ist klar, da brauchen wir nicht drüber zu reden. Ich habe allerdings die lästige Angewohnheit direkt in den Klassen-Deklarationen die Methoden zu kommentieren was den Header relativ unübersichtlich macht. Schöner ist es diese Kommentare für Doxygen mit @fn in der cpp zu erledigen. Das hat aber zwei Nachteile: Zum einen vergisst man dann oft den Kommentar anzupassen wenn man eine Methode ändert und zum anderen zeigt Eclipse sie dann nicht als QuickInfo an wenn man auf einem Methodenaufruf schwebt.
Im Code mache ich immer da Kommentare wo ich es für nötig halte. Um wieder auf obigen Kollegen zurückzukommen: Es ist nicht jeder ein Fachmann auf allen Gebieten und wenn ich Algorithmen lesen muss die von Mathematikern oder Physikern kommen verstehe ich sonst nur Bahnhof oder brauche erstmal eine Stunde mich da reinzudenken was dort passiert. Ähnlich geht es wohl dem Mathematiker oder Physiker wenn er meinen Grafik-Code sieht :mrgreen: Von daher ist kurzes, prägnantes Kommentieren absolutes Muss.
Es gibt auch Situationen in denen ich mehrzeiligen Kommentar in einer Implementierung für sinnvoll halte. Ein Beispiel für den o.g. Kollegen: Bugs in Qt. Wenn jemand meinen Workaround Code sieht dann wird er denken
Warum macht der das so kompliziert, da könnte man doch Methode xyz aus Qt für benutzen .... Und genau an solchen Stellen braucht es einen mehrzeiligen Kommentar warum das so ist, welchen externen Bug es umschifft und ob es z.B. schon eine Ticket-Nummer bei Qt dafür gibt.
Hier oute mich aber auch als /* */ Kommentierer weil ich das bei mehrzeiligen Kommentaren für übersichtlicher halte. Ich komme ehrlich gesagt auch sehr selten in Situationen wo ich ganze Blöcke ausklammern muss. Das tut man meiner Meinung nach nur, wenn man den Code gerade aktiv entwickelt und in einer solchen Situation hat man einen abschließenden Kommentar eh noch nicht geschrieben ;)
Ciao,
Stefan