Diskussion: "Clean Code" von Uncle Bob. Sinnvoll?

[RalphS]

Hmm... ich dachte es wäre herauszulesen gewesen, aber wohl nicht, deswegen nochmal:
*Es geht um "tendentiell", nicht "absolut". *

Es geht nicht um die eine Zeile Code mehr oder weniger. Natürlich ist es albern zu versuchen die eine einzige Zeile mehr oder weniger zu rechtfertigen, genauso wie es albern ist, auf Teufel komm raus noch den letzten Kommentar zu eliminieren.

Es ist auch egal, ob die Anwendung in 10µs läuft oder in neunen.

NICHT egal ist, wenn mein Code durch "Lesbarkeit" signifikant aufgebläht wird.
Ebenso nicht egal ist, wenn meine Anwendung in Abhängigkeit der Eingabe plötzlich kubisch läuft statt quadratisch oder gar in Echtzeit.

Lesbarkeit ja. Clean auch. Natürlich. Aber sekundär. Ich fahr auch nicht mit nem Trabi links auf der Autobahn, weil ich das ästhetisch finde.

 

[benneq]

NICHT egal ist, wenn mein Code durch "Lesbarkeit" signifikant aufgebläht wird.

Das kommt stark darauf an in welchem Umfeld man entwickelt. In einem normalen Java Projekt werde ich soweit möglich auf Bitshifting verzichten - oder zumindest derartigen Low-Level-Kram in Utility-Funktionen verstecken. In einem C Umfeld sieht's wieder anders aus.

Ebenso nicht egal ist, wenn meine Anwendung in Abhängigkeit der Eingabe plötzlich kubisch läuft statt quadratisch oder gar in Echtzeit.

Und genau da scheiden sich die Geister: Mir ist es in erster Linie vollkommen egal, ob mein Algorithmus in O(n) oder O(n^3) läuft. Zuallererst muss er fehlerfrei funktionieren und verständlich sein.
Es hängt ja auch davon ab, ob der Algorithmus auf Arrays mit 10 Elementen oder eher 10000 Elementen arbeitet. Bei 10 Elementen juckt's mich eben auch nicht, ob der Code 9µs oder 10µs braucht - dementsprechend interessiert mich auch nicht mit welcher Komplexität er läuft, solang er seine Aufgabe schnell genug erledigt.
Ob die Performance dieser Codestelle überhaupt relevant ist, und ob Optimierungen nötig sind, werden dann spätestens die Tests zeigen. Falls ja, wird der Code dann optimiert.

Ich fahr auch nicht mit nem Trabi links auf der Autobahn, weil ich das ästhetisch finde.

Das nicht. Aber wenn du mit deinem Auto nur alle 2 Wochen um den Block fährst, nimmst du doch lieber den hübschen Trabi als den Opel Corsa mit Sportfahrwerk.
Und auf der Autobahn kommt's dann auch noch drauf an, ob du der einzige Fahrer weit und breit bist, oder ob reger Verkehr herrscht. Wenn du nach vorne und hinten 100km Platz hast, stört's auch niemanden, ob du links oder auf dem Standstreifen, oder gar im Rückwärtsgang fährst.

 

[PHuV]

Natürlich sind Kommentare nicht inhärent schlecht. Sie müssen ebenso wie der Code kurz und knapp sein - detailliertere Erklärungen, die dafür sorgen, daß man 100 Zeilen Text mit 95 Zeilen Kommentar hat, sind natürlich ein Problem -- sie müssen sinnvoll sein - sowas wie

// addiere 1
a++;

ist ebenfalls Mumpitz.

Gerade solche Zähler hasse ich. Bei mir haben schon immer die Zähler Namen, so daß man sehen kann, was sie zählen.

anz_zeilen
minutenzähler

finde ich schlüssiger als Alphabet rauf und runter. Nur zz als zeilenzähler findet bei mir als Kürzel Verwendung. Gerade wenn man langen Code durchgeht und selbst bei der Variablendeklaration die Verwendung kommentiert hat, hat man das viele Zeilen weiter oder beim Debuggen schon wieder vergessen. Als Klarname dagegen kann man nicht anders, man weiß, wofür der Zähler ist, jederzeit.

Ich weiß noch, wie sich ein Vorgesetzter Anfang der 90er bei mir aufgeregt hatte, daß meine Zählernamen in Cobol immer so lange seien. War und ist mir egal, weil so kann ich meinen eigenen Code immer wieder schneller lesen und verstehen.

 

[#basTi]

Die meisten müssen an Fremdcode ran, der einem vor vollendete Tatsachen stellt, wo man “schnell“ ein paar Änderungen vornehmen soll. Da ist oftmals ein Zeit- und Budgetlimit drin, das sowas wie Refactoring trotz Notwendigkeit ein reines Wunschkonzert bleibt.

Hier stimme ich @benneq voll zu: wenn du schlechten legacy code nur erweiterst, ohne ihn zu refaktorieren, kommst du auf lange Sicht in Teufels Küche. Sehe ich aktuell bei einem Meiner Kunden (5 Mrd € Umsatz / Jahr). Der Code wurde immer nur „erweitert“ und mittlerweile ist das ding quasi unwartbar. Keine Chance. Die kleinsten Dinge brauchen wochen weil man sich über die Implikation und Abhängigkeit nicht klar ist.

 

[PHuV]

Stimme ich Dir vollkommen zu. Nur - was nützt mir das? Wenn der Kunde das nicht einsieht und auch nicht bezahlt, was willst Du da machen? Und meine Freizeit opfere ich dafür garantiert nicht. Du kannst es ja dann gerne mal beim Kunden oder knatischen Vorgesetzten probieren mit der Aussage "Hm, die Zielvorgabe von Ihnen haben ich nicht geschafft, aber dafür habe ich den Code schön aufgehübscht und lesbarer gemacht."

 

[#basTi]

Wie @benneq gesagt hat: vorher drüber reden. Bei uns gibt es mittlerweile die Regel: Code schöner hinterlassen als man ihn vorgefunden hat.
Teilweise benötige ich Stunden um Code zu verstehen (in der Funktion super simpel aber durch Spaghetti & Co unlesbar). Wenn man dann nach langer Zeit dahinter blickt und nur seine neue Code Zeile einfügt damit FeatureXYZ jetzt auch drin ist, dann hat man beim nächsten mal exakt den selben Krampf. Also lieber nach dem stundenlangen Versuch es zu verstehen es auch umschreiben damit das nächste mal leichter wird.
Einziges Problem bei uns: keine Testcases. Es ist schwer zu refaktorieren wenn man dannach nicht sicher sein kann ob alles noch so funktioniert wie vorher.

 

[Old Knitterhemd]

Lässt sich pauschal einfach nicht sagen.
Ich schreibe gerade eine alte IBM Anwendung um und ich habe noch nie so viele überflüssige Kommentare gesehen...

Das macht das ganze eigtl nur schlimmer, besonders mit den ganzen Fehlern in den Kommentaren, die man dann auch noch entziffern muss.

Allerdings habe ich hier auch so manche Funktion, die ohne Kommentare kaum nachzuvollziehen wäre (ich habe hier mit Funktionen von mehreren Hundert bis Tausend Zeilen Code zu tuen).


Was das angeht lobe ich mir moderne Entwicklung.

Code sollte ohne Kommentare verständlich und lesbar sein, sollte das irgendwie nicht möglich sein, sollten wenigstens die Kommentare problemlos lesbar sein ^^

 

[nerdalicious]

Ebenso nicht egal ist, wenn meine Anwendung in Abhängigkeit der Eingabe plötzlich kubisch läuft statt quadratisch oder gar in Echtzeit.

Ist das nicht ein Strohmann? Uncle Bob findet auch die Laufzeit sollte nicht beeinträchtigt werden in der Grössenordnung, aber ehrlich gesagt, wer würde das tun? Das ist gar kein Trade Off.

 

[mastaqz]

Wie @benneq gesagt hat: vorher drüber reden. Bei uns gibt es mittlerweile die Regel: Code schöner hinterlassen als man ihn vorgefunden hat.
Teilweise benötige ich Stunden um Code zu verstehen (in der Funktion super simpel aber durch Spaghetti & Co unlesbar). Wenn man dann nach langer Zeit dahinter blickt und nur seine neue Code Zeile einfügt damit FeatureXYZ jetzt auch drin ist, dann hat man beim nächsten mal exakt den selben Krampf. Also lieber nach dem stundenlangen Versuch es zu verstehen es auch umschreiben damit das nächste mal leichter wird.
Einziges Problem bei uns: keine Testcases. Es ist schwer zu refaktorieren wenn man dannach nicht sicher sein kann ob alles noch so funktioniert wie vorher.

Habe ich mir vor Jahren angewöhnt, klappt gut:
"We don't have time to do it right." => "Do you have time to do it twice?"

Dann gehört eben auch dazu, im Nachhinein für Legacy Code Tests zu schreiben.

 

[new Account()]

"We don't have time to do it right." => "Do you have time to do it twice?"

Manchmal kann man die Frage mit "ja" beantworten?
Beabsichtigt?

 

[MR2007]

Das sind meiner Meinung nach solche Philosophien, die entstehen, wenn man BWLer auf die Programmentwicklung loslässt - zumindest wenn man es so extrem anstrebt, wie manche propagieren. Als Programmierer sollte man einschätzen können, ob der Code für andere verständlich ist, verständlich gemacht werden kann oder eben erklärender Kommentare bedarf. Und manchmal ist es schlicht eine Kosten/Nutzung Abwägung, ob es mehr Arbeit ist ein komplexeres Problem direkt in Code zu zaubern und mit entsprechenden Kommentaren zu versehen oder erst verständlich (um)zuschreiben, um dann auf Kommentare zu verzichten. Grundsätzlich sollte man aber sowieso nie zu faul für Kommentare und Dokumentation sein. Un das Prinzip "Kommentare braucht man nur bei schlechtem Code" ist grob fahrlässig und schließt aus, dass es auch komplexere Probleme gibt. Die Aussage ist auch genauso pauschalisierend wie "Wer nicht kommentiert oder Kommentare nicht anpasst, ist einfach nur faul". Und auch wenn ich Code schreibe, dessen Struktur selbst erklärend ist, wo alle Bezeichner sinnvolle Namen haben, setzt das nicht voraus, dass andere das genauso sehen. Vorallem denken dann wieder manche Leute, wie hipp und cool sie doch sind, weil sie jetzt auf Kommentare grundsätzlich verzichten.

Und bei dem was heutzutage alles an Entwicklungskonzepten in irgendwelchen Seminaren und Workshops zum Besten gegeben wird, ist es kein Wunder, dass heutzutage einfachste Programme überdurchschnittlich viel Ressourcen verschwenden, durch den ganzen Overhead den man damit erzeugt und die ganzen Abhängigkeiten, die damit einhergehen.

Ich habe Programmieren hauptsächlich während meiner Schulzeit vor 15 Jahren durch Spieleentwicklung in der Indieszene gelernt, wo man zwangsweiße immer versucht hat das letzte Quentchen Performance rauszuholen, was alles absolut konträr zu Usability und Wartbarkeit war. Mittlerweile bin ich im wissenschaftlichen Bereich und entwickle Quantensimulationen - da ist es auch heute noch das gleiche.

Wenn es um komplexe, mathematische Zusammenhänge geht, mit einer Codebasis mit Millionen Zeilen, die von den Vorgängern oder Kollegen überwiegend schlecht bis gar nicht dokumentiert oder kommentiert sind und dazu keinerlei Standards entsprechen, da bist du froh um jeden Kommentar den zu findest.

 

[Slurpee]

Und manchmal ist es schlicht eine Kosten/Nutzung Abwägung, ob es mehr Arbeit ist ein komplexeres Problem direkt in Code zu zaubern und mit entsprechenden Kommentaren zu versehen oder erst verständlich (um)zuschreiben, um dann auf Kommentare zu verzichten.

Ich dachte BWLer denken so? Das Problem ist einfach, dass den schlechten Code zu kommentieren IMMER die einfachste Lösung ist, aber so auf Dauer immer mehr und mehr Probleme hinzukommen, bis irgendwann die ganze Codebasis weggeschmissen werden kann.

Du zahlst IMMER. Die Frage ist nur, wann und wie viel. Und grade die BWLer sind doch diejenigen, die sich immer dagegen sträuben, mal aufzuräumen und kurzfristig weniger features durchzukriegen, um auf Dauer die performance zu erhöhen. Ich kenne keinen Entwickler, der sich freiwillig gegen ein sinnvolles Refactoring ausgesprochen hätte, sowas wird immer von den lieben BWLern beschlossen...

Vorallem denken dann wieder manche Leute, wie hipp und cool sie doch sind, weil sie jetzt auf Kommentare grundsätzlich verzichten.

Und manche Leute denken, sie sind erfahren, abgebrüht und "vom alten Eisen", wenn sie es nicht mal versuchen. Wie du schon sagst, es gibt Extreme in beide Richtungen...

Und bei dem was heutzutage alles an Entwicklungskonzepten in irgendwelchen Seminaren und Workshops zum Besten gegeben wird, ist es kein Wunder, dass heutzutage einfachste Programme überdurchschnittlich viel Ressourcen verschwenden, durch den ganzen Overhead den man damit erzeugt und die ganzen Abhängigkeiten, die damit einhergehen.

Wie oben schon gesagt: Coden, auf Wartbarkeit und Erweiterbarkeit achte, testen, profilen und DANN optimieren und auch nur, wenn der Kunde es will. Das ist nämlich auch so ein Punkt, da optimieren Leute die Erweiterbarkeit weg, obwohl kein Mensch sich über die Performance beschwert hat und die schlechte Erweiterbarkeit tatsächlich ein Problem ist.

Ich habe Programmieren hauptsächlich während meiner Schulzeit vor 15 Jahren durch Spieleentwicklung in der Indieszene gelernt, wo man zwangsweiße immer versucht hat das letzte Quentchen Performance rauszuholen, was alles absolut konträr zu Usability und Wartbarkeit war. Mittlerweile bin ich im wissenschaftlichen Bereich und entwickle Quantensimulationen - da ist es auch heute noch das gleiche.

Dann bist du eben einer der wenigen Leute, bei denen das wirklich Sinn macht/Notwendig ist. Ich bekomme demnächst jedenfalls einen Anfall, wenn ich noch ein paar mal Spahgetti code in einer simplen Business Anwendung sehe, weil "ist performanter".

Wie gesagt, man muss nicht alles wie einen Kernel Patch oder einen Grafikkartentreiber behandeln...

Wenn es um komplexe, mathematische Zusammenhänge geht, mit einer Codebasis mit Millionen Zeilen, die von den Vorgängern oder Kollegen überwiegend schlecht bis gar nicht dokumentiert oder kommentiert sind und dazu keinerlei Standards entsprechen, da bist du froh um jeden Kommentar den zu findest.

Jo, wenn man sich nicht an die Regeln des clean code hält, darf man eben auch nicht auf Kommentare verzichten, wenn schon, denn schon, man kann sich nicht nur die "tollen" Sachen rauspicken.

 

[GustlPC]

Ich habe mir jetzt hier nicht alles durchgelesen, aber ich habe mir mal sagen lassen, dass kommmtare nicht das wieder geben was der Code macht, sondern warum man es macht. Das versuche ich in meinen Code zu beachten.

 

[Nolag]

Die Frage ist nur, wann und wie viel. Und grade die BWLer sind doch diejenigen, die sich immer dagegen sträuben, mal aufzuräumen und kurzfristig weniger features durchzukriegen, um auf Dauer die performance zu erhöhen. Ich kenne keinen Entwickler, der sich freiwillig gegen ein sinnvolles Refactoring ausgesprochen hätte, sowas wird immer von den lieben BWLern beschlossen...

Das ist der entscheidende Punkt. Die Entwickler würden gerne vernünftige Qualität liefern, aber Projekte werden heute häufig vom Kostenrahmen als "Mission Impossible" angelegt, weil die Verantwortlichen glauben, dass sie so am meisten für ihr Geld bekommen. In der Softwareentwicklung ist das aber meistens kontraproduktiv. Da kann man eigentlich nur kündigen und besser irgendwo arbeiten, wo man agile Entwicklung verstanden hat.

 

[Reverse]

Code muss ohne Kommentare lesbar sein, ist er es nicht, ist es schlechter Code.
Ergänzt mit einem gescheitem Diagram hat man da mehr gewonnen.

Nur Dinge die von Natur aus schwer verständlich sind müssen kommentiert werden.

Grund: Da arbeiten mehrere Leute dran, teils über Jahre. Keine Sau wird darauf achten die Doku immer wieder mitzuziehen. Am Ende steht da was falsches und schadet mehr als es nutzt. Die Lehren aus dem Studium kann man vergessen. In der Realität findet man nur Amateur-Code vor. Der ensteht nicht weil Amateure daran arbeiten, sondern weil zu viele Leute über die Jahre hinweg da rumwursten und jeder Entwickler seinen eigenen Stil verewigt.

 

[PHuV]

Na ja, wenn eine Firma gut arbeitet, gibt es sehr wohl Styleguides. Wenn ich beispielsweise als Externer dort arbeite, mache ich genau das, ich halte mich an deren Styleguide, auch wenn ich es besser kann oder besser weiß oder es nicht mag, es spielt keine Rolle. Der Kunde bestimmt die Regeln und bezahlt meine Kohle. Klar kann man ihm mal darüber diskutieren, etwas zu verbessern. Aber alle die, die in entsprechend großen und "etablierten" Firmen arbeiten, kennen die Situation dort sehr gut, um zu verstehen, daß es vielfach sinnlos ist.

 

[benneq]

Keine Sau wird darauf achten die Doku immer wieder mitzuziehen.

Das ist ein wirklich entscheidender Punkt. Hat aber auch wieder einiges mit den wirtschaftlichen Interessen des Unternehmens zu tun. Funktion anpassen ist die eine Sache, aber die Dokumentation entsprechend anzupassen verdoppelt schnell die Kosten. Wenn dann noch Tests dazukommen, die angepasst werden müssen... Auweia.
Deshalb ist TDD auch mehr Utopie als Realität. Für Kernkomponenten benutzt ich zwar auch ausführlich TDD, aber beim Rest sehe ich das nicht ein, da ich aus eigener Erfahrung weiß, dass dort in der Regel alles problemlos verläuft, solang die Kernbibliotheken wirklich sauber arbeiten.
Und wenn ich für alles Tests schreiben würde, bin ich mir ziemlich sicher, dass ich bei den nächsten Änderungen die Tests vergessen habe, und dann vom CI System drauf hingewiesen und mich dann ärgern werde, dass ich dann von einem Task wieder zurück zum anderen muss, um auch noch die Tests anzupassen.
Bei der Dokumentation hat man dagegen den Vor- und Nachteil, dass sie sich nicht testen lässt und es erst auffällt, wenn jemand die Funktion verstehen will und nichts mehr zusammenpasst.

 

[ascer]

Um nochmal direkt auf diese Ursprungsfrage einzugehen:

"Clean Code" sagt im Prinzip, dass Kommentare so weit wie möglich vermieden werden sollen, da man sonst mehr zu pflegen hat (code+comment).

Meiner Meinung nach hängt das stark von der Applikation ab. In meinem Umfeld, DataScience & AI, wären Applikationen ohne Kommentare undenkbar respektive tatsächlich sehr schlecht.

Ich bin da meistens ein Anhänger des "Zen of Python"

Explicit is better than implicit

Die Wartung von Code+Comment finde ich im Übrigen auch gar nicht so problematisch. Auch abseits von Microservices habe ich im Produktivumfeld bisher sehr viel Modularisierung beobachten können und bin da durchaus ein Fan von.

Sprich: ein Stück Code sollte einfach nur eine einzige Aufgabe umsetzen und das ordentlich.

Ich würde nun nicht ausschließen, dass z.B. Desktop-Applikationsentwicklung mehr Produktpflege benötigt, bei der immer und immer wieder an bestimmten Teilen rumgedoktert wird...aber in solche Edge-Cases bin ich nie vorgestoßen.

Minimalistisch, gut kommentiert und wenn sich der Einsatzzweck ändert, dann werden eher neue Module geschrieben.
Im Prinzip wie bei den guten, großen Libraries: Lapack, Eigen, NumPy, ... die sind so sauber und erreichen das dadurch, dass man ordentliche Interfaces definitiert und die dann freezed. Wenn dann neue Funktionalität benötigt wird, dann kommen eher neue Module hinzu als das stehender Code zig mal überarbeitet wird, weil das einfach immer Seiteneffekte bei jedem noch so kleinen Schnipsel erzeugt, der den Code irgendwo irgendwann mal benutzt.

 

[mistalan]

Ich bin jetzt seit mehr als 12 Jahren Softwareentwickler und betreibe Clean Code aktiv für ca. 6 Jahre.

Aus Erfahrung kann ich folgendes sagen:
1) Es fehlen verbindliche Standards in der Software Entwicklung
2) Es gibt Prinzipien/Methodiken über die man diskutieren kann. Clean Code gehört nicht dazu. Auch wenn es für einige unbequem ist das zu akzeptieren. (Es gibt weitere Punkte die ich dazu zähle, wie z.B. TDD)
3) Ich möchte meine ersten Jahre als Berufsanfänger mit hässlichem, unleserlichen mit Anti-Patterns bestückten Code nicht missen. Ohne ihn wäre ich nicht da wo ich jetzt bin und könnte die ganze Tragweite von CC gar nicht richtig wertschätzen.
4) Kommentare sind zu 99% unnötig, falsch und gefährlich. Ich habe in Teams mit bis zu 50 Entwicklern gearbeitet. Niemand liest Kommentare wirklich und versteht sie so, wie sie gemeint sind.
Der beste Kommentar ist - neben dem Produktivcode - der Unit Test.
Dort erkenne ich wie ein System designed wurde, welche Objekte benutzt werden und wie man sie kombiniert. Die restlichen 1%: Öffentliche APIs, Stellen im Code die für andere Entwickler nach Smell "riechen" jedoch aus z.B. Performance Gründen unausweichlich sind, Copyright Disclaimer.
5) ca. 50% der weltweiten Entwickler haben eine Berufserfahrung < 5 Jahre (geschätzt von Uncle Bob). Dies führt wegen 3) dazu, dass nur wenige Clean Code beherrschen und wegen 1) kann man ihnen nicht mal einen Vorwurf machen.
6) Es ist mühselig aber ich versuche immer wieder mein Wissen (und meine Fehler in aus der Vergangenheit) an neue Kollegen weiterzugeben und beharre bei "alten Hasen" auf eine disziplinierte Arbeitsweise mit Clean Code und allem was dazu gehört. Das macht mich oft nicht gerade beliebt, hilft aber auf lange Sicht immens.
7) Eitelkeit, Egoismus, Überschätzung, Beharren auf Legacy, etc. ist Gift in unserer Branche. Kritik muss sachlich sein und sollte niemals persönlich aufgenommen werden. Das spiegelt sich aber leider auch hier in diesem Thread wider.

 

[G00fY]

Ich bin jetzt seit mehr als 12 Jahren Softwareentwickler und betreibe Clean Code aktiv für ca. 6 Jahre.

Bei mir ists genau die Hälfte jeweils. 6 Jahre beruflich als Entwickler tätig und seit 3 Jahren bewusst mit Blick auf Clean Code sowie Prinzipien wie SOLID, IoC, reactive programming etc. Bei mir im Bereich B2B und B2C Mobile Apps. Schließe mich deinem Kommentar zu 100% an.

Nur kurz zu Punkt 1: Es sollte in jeder Firma/Abteilung/Team verbindliche Standards geben. Es gibt nur eben keine/wenige übergreifende Standards. Das hat aus meiner Sicht Vor- und Nachteile. Man muss halt neue Kollegen intensiver einarbeiten. Mit entsprechenden Qualitätsvorkehrungen (commit-hooks, statischer Codeanalyse, Pull Requests, automatisierten Tests etc.) kann man solche Standards aber imo sehr gut forcieren. Wir nutzen zB zusätzlich auch Analysen um Code-Smell frühzeitig zu erkennen. Also Klassen oder Methoden deren LOC eine bestimmte Anzahl übersteigt fallen dadurch auf.