Clean Code und (vs?) Strukturierte Programmierung?
Als Anwendungsentwickler kenne ich natürlich beide Begrifflichkeiten. Mir ist allerdings aufgefallen, besonders auch in Bezug eines Clean-Code-Seminars, dass anscheinend innerhalb von Clean-Code das Thema strukturierte Programmierung keine Erwähnung zu finden scheint. Noch schlimmer sogar, der Dozent zeigte ein Beispiel einer Swtich-Anweisung, bei der jede Fallunterscheidung in ein return (also fluchtartiges Verlassen der Routine) mit irgendeinem Wert mündete und meinte, das sei Clean-Code :-D.
Bei früheren Arbeitgebern in den letzten 10 Jahren habe ich u.a. fluchtartiges Verlassen von Schleifen (break), Rücksprünge zum Anfang der Schleifen (continue) und nicht zuletzt auch frühzeitiges Verlassen von Routinen (return) gesehen(, erlebt und dabei den Kopf geschüttelt)! Eine externe Fachkraft adelte die letzte Stilform mit "early Return" und hielt das für besonders pfiffig.
Bei meinem letzten Arbeitgeber waren die Kollegen sehr an Clean-Code interessiert und lernten das fleißig auf einschlägigen Seiten. Aber auch sie bevorzugten gerne, so wie ich es nenne "Mittendrin-Returns". Das ging sogar so weit, dass innerhalb von Catch-Blöcken gerne mal Returns formuliert wurden, was den eigentlichen Sinn und Zweck vom Exception-Handling in der Sprache Java ad absurdum führt.
Ist in den Bildungsstätten die Strukturierte Programmierung völlig abhanden gekommen, oder gilt diese mittlerweile als überholt? Habe ich die Stelle wo in den Clean-Code-Regeln, in der auf strukturierte Programmierung eingegangen wird nur übersehen, oder hat man das Thema da, aus meiner Sicht bedauerlicherweise, ausgespart oder gar ignoriert?
2 Antworten
Wie chriss1967 schon schreibt: CleanCode beschäftigt sich hauptsächlich damit, den Code lesbar, leicht verständlich und übersichtlich zu machen. Ob ein return nun mittendrin oder immer am Ende steht, hat damit nicht viel zu tun. Ein "early return" kann sinnvoll sein, es kann aber auch furchtbar sein, wenn die Methode sehr lang/komplex ist, dann ist aber der generelle Aufbau der Methode das Problem und nicht das "early return".
Und weil dir das "early return" so wichtig zu sein scheint, gehe ich da nochmal explizit drauf ein:
Swtich-Anweisung, bei der jede Fallunterscheidung in ein return [...] mit irgendeinem Wert mündete und meinte, das sei Clean-Code
Ist es auch und mache ich häufig auch so.
Sinn und Zweck ist eine Art Mapping aufzubauen und da ist es hilfreich, eine optisch leicht "erfassbare" Struktur zu bieten. Das "return" kann dabei helfen, da es häufig farblich hervorgehoben wird.
Auf der anderen Seite macht es den Code auch leichter verständlich, da einm return immer am Ende der Methode auch bedeutet, dass nach dem case noch mehr kommen kann. In vielen Fällen ist das aber gar nicht der Fall, also warum sollte ich dem Leser suggerieren, dass nach dem case noch etwas kommen könnte?
Bei früheren Arbeitgebern in den letzten 10 Jahren habe ich u.a. fluchtartiges Verlassen von Schleifen (break), Rücksprünge zum Anfang der Schleifen (continue) und nicht zuletzt auch frühzeitiges Verlassen von Routinen (return) gesehen(, erlebt und dabei den Kopf geschüttelt)!
Auch das ist sinnvoll und häufig auch notwendig.
break
Wenn ich z.B. eine foreach- oder eine while-Schleife habe, die irgendetwas komplexes tut und ich stelle darin fest, dass ich die Arbeit einstellen kann: Warum sollte ich die Schleife noch weiter laufen lassen? Dahinter könnte z.B. eine Datenbank-Query stehen, da nicht abzubrechen, wäre dann sogar schädlich.
Außerdem ist das auch hier eine farblich auffällige geschichte. Wenn Du den Fall hast, dass Du ab einen Bestimmten Punkt nichts mehr tun musst, aber kein break benutzen willst, müsstest Du alternativ eine Variable nutzen und in der Schleife prüfen. Das if erhöht dann die Einrückung der gesamten Methode und Du hast eine weitere Kontrollstruktur, was die generelle Lesbarkeit verschlechtert.
continue
Gleiches auch hier. Was ist, wenn Du bei einem einzelnen Datensatz nichts mehr tun musst? Du könntest eine Variable erstellen und den ganzen folgenden Code in ein if stecken, das erhöht wiederum die Einrückung und stört die Lesbarkeit. Und bei komplexen Fällen brauchst Du dann ggf. mehrere Variablen, die in verschiedenen Fällen den folgenden Code überspringen (= viele Variablen ohne direkten Zusammenhang dort, wo sie genutzt werden), oder Du baust eine generische Variable, aber dann kannst Du auch gleich break/continue nutzen.
return
Siehe oben
Ist in den Bildungsstätten die Strukturierte Programmierung völlig abhanden gekommen, oder gilt diese mittlerweile als überholt?
Ich hatte das auch mal gehört, halte das aber für keine gute Pauschal-Regel. Da, wo ein "early return" ein Problem ist, ist häufig die Methode selber das Problem und nicht das "early return" im eigentlichen Sinne. Das "early return" wird dann zum Problem, wenn die gesamte Methode nicht gut oder zu groß/unübersichtlich geschrieben wurde.
Die häufigste Alternative wäre dann irgendeine Status-Variable (z.B. Status-Code), die die allgemeine Komplexität erhöht und den Ablauf generell schwieriger nachzuvollziehen macht, weil der Ablauf im case (oder wo auch immer das return wäre) nicht zuende ist, sondern man erst das tatsächliche Ende suchen muss.
Außerdem habe ich die Erfahrung gemacht, dass solche Status-Variablen sehr schlecht altern, es wird schnell mal ein zweiter Status hinzugefügt (z.B. als int-Variable), der dann ggf. den ersten Status kaputt macht. Gerade bei komplexen Methoden ist das ein Problem - aber ja, in solchen Fällen ist die Methode das eigentliche Problem.
-----------------
Das wichtigste beim Thema CleanCode ist, dass die Methode leicht erfassbar bleibt, das kann ein "early return" ausschließen, muss es aber nicht. Es bleibt immer eine Abwägung, pauschal das "early return" zu verbieten halte ich für einen Fehler.
Und vor allem ist das auch von der verwendeten IDE abhängig, da z.B. Visual Studio einige Dinge klug hervorhebt, z.B. foreach, continue und break wird immer gemeinsam hervorgehoben.
Das was du ansprichst gehört (zumindest nach meinem Verständnis und das unserer Dozenten) nicht zu Clean-Code sondern generell zu OOP. Clean-Code beschäftigt sich nicht mit der Struktur einzelner kleiner Code-Blöcke oder Methoden, sondern mit dem Gesamtbild des Codes. Wie sind Klassen strukturiert? Wie greife ich auf Daten zu? Wie ermögliche ich einen reibungslosen Austausch der Datenbank in der Zukunft? Das sind Fragen mit denen sich Clean-Code beschäftigt. Du redest allerdings von generellem Code-Design in der Objekt orientierten Programmierung.
Mich interessiert noch eine Sache: was wäre denn deine Alternative zu den returns im Switch-Satement?
Wie würdest du es denn machen, meinte ich damit. Offensichtlich findest du Return-Statements in einem Switch nicht die beste Lösung. Was wäre demnach deine Lösung dafür?
Ich glaube, ich hab dich schon richtig verstanden, aber meine Antwort war unter anderem auch an den Fragesteller gerichtet, weil ich gerne wüsste, wie er es machen würde. Ich habe keine Probleme mit Continue, Return, Exit oder wie auch immer das entsprechende Statement in der jeweiligen Programmiersprache heißt. Und auch ich bin der Meinung, dass das mit Clean Code nicht wirklich viel zu tun hat. Es gehört tatsächlich in den Bereich OOP. Und auch da ist es nicht wirklich verboten.
Oh sorry Mal wieder falsch geschaut :) Dachte du wärst der Fragesteller. Entschuldige. Dann stimme ich dir natürlich zu
Ich denke schon, dass die Frage wann/wo man ein return hat, für CleanCode relevant ist. Es ist ja nicht nur auf OOP beschränkt, ein return gibt es praktisch überall, überall muss der Ablauf einer Methode/Funktion definiert werden und im CleanCode geht es darum, dass eben dieser Ablauf durch den Leser leicht erfasst werden kann.
Mich interessiert noch eine Sache: was wäre denn deine Alternative zu den returns im Switch-Satement?
Ich kenne noch die Variante, dass du einen return type festlegst (z.B. int als Error Code oder dergleichen) und dann auch im Falle eines switch() zumindest bis zu einem singulären return-Punkt am Ende der Methode gehst, damit du da z.B. ein aussagekräftiges Logging unterbringen kannst, anstelle von zig Loggings vor den returns in den einzelnen switch-cases.
Ist für die spätere Analyse oder sogar ein Debugging enorm hilfreich.
Ja das hatte ich auch im Kopf aber macht es das besser? Ich füge zusätzlich eine variable ein und mache das logging direkt in der Methode. Ich kann aber auch die variable weglassen und das logging in die Aufrufende Methode stecken, wo ich ja die Return-Daten bekomme. Daher verstehe ich nicht so ganz was an den Return-Statements im Switch so schlimm sein soll
Wirklich schlimm nicht. Aber wenn du z.B. im Visual Studio arbeitest, kannst du dir im Logging auch den Stack Trace ausgeben lassen. Das geht nicht in der aufrufenden Funktion.
Und wenn ich einen hypothetischen switch() mit 6 returns habe, dann habe ich da 6 points of exit, die alle mit einem entsprechenden Logging versehen werden müssten. Wenn ich stattdessen einen ErrorCode verwende, habe ich einen single point of exit, es gibt kein ggf. unkontrolliertes Rausspringen aus der Methode nebenher, es gibt eine einzige Exit-Logginganweisung und wenn ich zwingend Zykluszeiten sparen will, kann ich nach dem Switch immer noch ein state flag oder den gesetzten ErrorCode auswerten, welches dann im Hintergrund sowieso zu einem JNE [ende] ausgewertet wird.
wenn du z.B. im Visual Studio arbeitest, kannst du dir im Logging auch den Stack Trace ausgeben lassen.
Was meinst Du damit? Ich würde behaupten, ich kenne mich ziemlich gut mit Visual Studio und C# aus, eine gängige Funktion, den Stacktrace im Logging zu zeigen, kenne ich aber nicht.
Ggf. meinst Du Debugging?
Und im Log kann man durchaus den StackTrace ausgeben lassen, das wäre allerdings eine furchtbare Idee und würde jede Performance auf einen Schlag töten ^^
Wenn ich stattdessen einen ErrorCode verwende, habe ich einen single point of exit, es gibt kein ggf. unkontrolliertes Rausspringen aus der Methode nebenher
Ich sehe ein single point of exit nicht unbedingt als Argument. Es kann schön sein, wenn der Code dabei weiterhin einfach bleibt, aber es ist für mich kein konkret angestrebtes Ziel.
Viel eher befürchte ich, dass so ein ErrorCode (oder irgendein Status, der dafür nötig wäre) den Rest der Methode davor noch verkompliziert, da sich dieser Status zwischendrin ändern kann - was meiner Erfahrung nach leider auch vorkommt.
Da finde ich das "vorzeitige" (mMn. ist es nicht unkontrolliert, s.u.) Rausspringen aus der Methode deutlich besser, da die Komplexität der einzelnen Abschnitte reduziert und ich an jeder Stelle, wo ich ein return finde, weiß: Hier ist schluss.
Und zum Thema *unkontrolliertes* Rausspringen: Ich finde das nicht "unkontrolliert", da man ja vorher explizit prüft, ob der folgende Code noch ausgeführt werden sollte, oder nicht.
Ich sehe bei "vorzeitigen" returns nur das Risiko, dass bei späterer Bearbeitung der Methode etwas ergänzt wird, was dann nicht in allen Fällen ausgeführt wird, wo es ausgeführt werden müsste. Dann hat aber der Entwickler gepennt, oder die Methode war allgemein zu komplex, dass das nicht sofort aufgefallen ist. Verhindern würde ein Status das aber auch nicht, da es ja immer noch vorkommen kann, dass durch irgendwelchen Abläufe ein falscher Status entsteht, oder der Entwickler übersieht durch die vorherigen Abläufe, dass der neue Code z.B. in zwei Stati ausgeführt werden müsste.
--------------
In jedem Fall ist es eine Abwägung.
Ich habe schon Code geschrieben, der einen solchen Status genutzt hat, dann war dieser Status aber auch explizit Teil der Logik und wichtig für das Verständnis und nicht nur Mittel zum Zweck, um kein vorzeitigen return zu haben.
Ich schreibe aber auch häufig Code, wo die Methode früher endet, z.B. wenn ich in mehreren Schritten etwas prüfe und jedes Mal, beim ersten Erfolg einer Prüfung "return true" mache.
-------------
Und Thema Logging:
Ich tendiere dazu, Logs in Erweiterungsmethoden (C#-Feature) zu schreiben. Das passt auch schön mit einem CodeGenerator für "das" .NET Logging-Framework zusammen, der unter Anderem für Erweiterungsmethoden spezifisch optimierten Log-Code generiert. Diese Methoden kann ich dann auch problemlos mehrfach in einer Methode aufrufen und habe außerdem sprechende Namen.
Das funktioniert natürlich in anderen Programmiersprachen nicht genauso, aber ich würde mir ggf. ein ähnliches Konzept überlegen, ggf. statische Methoden in Klassen gruppiert nach Anwendungsbereich?
Was meinst Du damit?
So etwas wie: System.Environment.StackTrace
Und im Log kann man durchaus den StackTrace ausgeben lassen, das wäre allerdings eine furchtbare Idee und würde jede Performance auf einen Schlag töten ^^
Bevor ich im Problemfall im Trüben fische, setze ich gerne ich Programm den LogLevel hoch (bis hin zu Traces), "töte auf einen Schlag jede Performance" :), weiss aber dafür verdammt schnell, was in den einzelnen Methoden abgeht.
Voraussetzung dafür ist natürlich, dass auch entsprechendes Logging implementiert ist.
...Ich sehe bei "vorzeitigen" returns nur das Risiko, dass bei späterer Bearbeitung der Methode etwas ergänzt wird, was dann nicht in allen Fällen ausgeführt wird, wo es ausgeführt werden müsste.
Und exakt das ist es, was ich schon so oft erlebt habe, dass ich es nicht mehr zählen kann. Das Schlimme sind auch nicht die offensichtlichen Fälle, wo eine Logik nachträglich ergänzt wurde, sondern wo ein tief eingebetteter return in einem Source ohne jegliche Dokumentation dazu führt, dass notwendige Logikschritte übersprungen werden.
Dann hat aber der Entwickler gepennt, oder die Methode war allgemein zu komplex, dass das nicht sofort aufgefallen ist.
Was - wiederum für mich ein Erfahrungswert - in mehr(!) als 9 von 10 Fällen vorkommt.
Irgendwann habe ich aufgehört, vom perfekten Zustand (clean code, Übersichtlichkeit, KISS, Dokumentation) zu träumen und mich dem gestellt, was mir ad nauseum immer wieder real begegnet ist.
In jedem Fall ist es eine Abwägung.
Absolut. Bei einer 5 bis 10-Zeilen-Methode (sofort auf einen Blick am Bildschirm ersichtlich) hätte ich auch kein Problem mit fehlendem Logging und direkten returns.
So etwas wie: System.Environment.StackTrace
Ja das kenne ich, habe ich aber noch nie im Log gebraucht.
Ich hatte aber auch noch nie einen Fall, wo ich nicht auf anderen Weg nachvollziehen konnte, was passiert ist - ohne riesigen Aufwand.
Allerdings muss ich auch dazu sagen: Ich kann nicht einfach hingehen und das LogLevel hoch drehen, dann rennt mir nach 10 Minuten der Kunde die Türe ein :D
Und bei einer Exception oder beim Debuggen habe ich den StackTrace ja sowieso.
Auf der anderen Seite:
Wäre dann nicht ggf. eine andere Form von Logging angebracht? Z.B. habe ich vor einigen Jahren ein Logging jedes Commands (damals jeder WCF-Call) mit allen Input-Daten und Zeitpunkt geloggt und DB-Backups gab's alle 5 Minuten. Ich konnte also bei jedem Fehler hingehen, mir den Stand ziehen und genau diesen einen problematischen Fall debuggen.
Und exakt das ist es, was ich schon so oft erlebt habe, dass ich es nicht mehr zählen kann.
Naja, aber das return zwingend ans Ende der Methode zu schieben, behebt das Problem ja nicht, es tritt dann nur in einem anderen Zusammenhang auf.
wo ein tief eingebetteter return in einem Source ohne jegliche Dokumentation dazu führt, dass notwendige Logikschritte übersprungen werden.
Naja, wir sind hier ja beim Thema CleanCode, wir betrachten also das "Wie sollte es sein" und das "Wie ist es tatsächlich".
Beim "wie sollte es sein" würde ich sagen, ist deine beschriebene Situation gar nicht relevant, weil keine Methode so komplex ist, dass es ein "tief eingebettetes return" gibt. Selten kommt das schon mal vor, aber das sind dann Algorithmen, die auch mit einem einzigen return am Ende schwer zu durchblicken wären und ggf. auch die Fälle, wo ich das auch so machen würde. Die Mehrheit ist aber einfacher.
Und beim "Wie ist es tatsächlich" haben wir ja leider das Problem, dass viele Kollegen leider keinen Wert auf CleanCode legen oder sich zu wenig Gedanken machen (sich darauf verlassen, dass es der Senior beim Review schon fixt). Solche Leute machen die von dir beschriebenen Fehler so oder so, egal ob man nun ein return am Ende, oder mehrere in der Mitte hat.
Irgendwann habe ich aufgehört, vom perfekten Zustand zu träumen und mich dem gestellt, was mir ad nauseum immer wieder real begegnet ist.
Mein Problem mit einer pauschalen Regel "return nur am Ende" ist, dass ich eben auch gelernt habe, wie massiv das nach hinten losgehen kann. So habe ich z.B. an einem Projekt gearbeitet, das durchgehend mit Status-Codes gearbeitet hat, um das "Ende" der Methode zu verwalten - also im Grunde das, was Du hier forderst.
Das Problem war, dass es in diesem Projekt sehr häufig sehr tiefe if-Verschachtelungen gab, um irgendwelche Status-Codes durch zu testen. Da ist am Ende genau das passiert, was Du eigentlich vermeiden willst: Keiner hat mehr überblickt, wann was passieren sollte und häufig wurde irgendetwas übersehen.
Gut, in dem Projekt (naja, in der Firma) ist noch einiges mehr schief gegangen, aber genau darum geht es ja:
Dieses Vorgehen verhindert die von dir beschriebenen Probleme nicht, es verlagert sie nur. Sorgfältiges Arbeiten aller Beteiligten verhindert diese Probleme und das erreicht man leider nicht mit CleanCode - aber vielleicht mit Debatten darüber ^^ Jeder einzelne sollte CleanCode verfolgen, je mehr die Leute sich damit befassen, desto mehr achten sie auch darauf und umso besser wird der Code.
Ich behaupte mal, CleanCode an sich hat eine gewisse Relevant, wirklich entscheidend sind aber nicht die CleanCode-Regeln, sondern die Tatsache, dass die Leute sich mit eben diesen Regeln befassen, selbst wenn sie sie am Ende doch nicht befolgen - hoffentlich nach reiflichen Überlegungen.
Bei einer 5 bis 10-Zeilen-Methode (sofort auf einen Blick am Bildschirm ersichtlich) hätte ich auch kein Problem mit fehlendem Logging und direkten returns.
"5 bis 10 Zeilen" würde ich nicht als Kriterium nehmen, eher das "sofort auf einem Blick ersichtlich", bzw. ich achte darauf, dass ich ohne viel Nachdenken einen Überblick über den generellen Ablauf der Methode bekommen kann. Ist ein sehr gefühltes Kriterium, aber es funktioniert gut und bisher hat sich noch nie jemand über zu komplexen Code von mir beschwert ^^
Jedenfalls habe ich nur sehr selten eine Methode, auf die das nicht zutrifft, weil ich mir viel Mühe gebe, dass der Code gut erfasst werden kann. Vielleicht habe ich daher auch kein Problem mit returns in der Mitte.
Bei bestehendem Code sieht das natürlich anders aus, aber wenn ich dort sowas wie return-Regeln anwenden will, muss ich refaktorisieren, dann kann ich auch gleich die Methode an sich übersichtlicher gestalten, oder?
also im Grunde das, was Du hier forderst.
Fordere? Ich fordere gar nichts. Ich habe lediglich auf
was wäre denn deine Alternative zu den returns im Switch-Satement?
reagiert. Du lieber Himmel, wie andere das in ihrem Code handhaben ist mir doch vollkommen egal. Da habe ich gar nichts zu "fordern". Ich denke, da hast du etwas rein interpretiert, was nicht vorhanden war.
Lediglich inwiefern multiple exit points auch nur annähernd übersichtlicher sein sollen wie ein single exit point (per definitionem) erschliesst sich mir nicht. Muss es aber auch nicht. :)
...Das Problem war, dass es in diesem Projekt sehr häufig sehr tiefe if-Verschachtelungen gab, um irgendwelche Status-Codes durch zu testen. Da ist am Ende genau das passiert, was Du eigentlich vermeiden willst: Keiner hat mehr überblickt, wann was passieren sollte und häufig wurde irgendetwas übersehen...
Das ist genau die gleiche Unübersichtlichkeit, die du erwähnt hast: Kein Clean Code vorhanden. Also insofern auch nicht relevant, wenn du meine Argumentation ebenso mit dem Argument "Thema ist Clean Code" abhakst.
Ich behaupte mal, CleanCode an sich hat eine gewisse Relevant, wirklich entscheidend sind aber nicht die CleanCode-Regeln, sondern die Tatsache, dass die Leute sich mit eben diesen Regeln befassen, selbst wenn sie sie am Ende doch nicht befolgen - hoffentlich nach reiflichen Überlegungen.
Darf ich das als Fazit für die nächste Schulung verwenden? Gefällt mir nämlich außerordentlich gut.
Ist ein sehr gefühltes Kriterium, aber es funktioniert gut und bisher hat sich noch nie jemand über zu komplexen Code von mir beschwert ^^
Ja, das ist ein "gefühltes" oder "schwammiges" Kriterium - genauso wie meine Aussage "5-10 Zeilen". Es geht tatsächlich rein um die Übersichtlichkeit. Natürlich sind das - je nach Monitorauflösung - auch mehr Zeilen. Aber da wir hier tatsächlich - imho - vernünftig im Bereich Coding diskutieren, dachte ich nicht, dass ich Selbstverständlichkeiten hervorheben / disclaimern muss.
Vielleicht habe ich daher auch kein Problem mit returns in der Mitte.
BINGO!
Wenn die Methode übersichtlich ist und ich auf EINEN Blick die exit points erfassen kann - alles bestens. Habe ich kein Problem damit. Hau so viele returns rein, wie du lustig bist und brauchst. :)
muss ich refaktorisieren, dann kann ich auch gleich die Methode an sich übersichtlicher gestalten, oder?
Absolut. Mein großer Bremsklotz an dieser Stelle sind immer Controlling und Budgetierung. :D Ansonsten bin ich da komplett bei dir.
Fordere? Ich fordere gar nichts. Ich habe lediglich auf
Das "fordern" sollte nichts unterstellen, ist nur meine Wortwahl, die ich in solchen Debatten verwende, um darzustellen: Deine Sichtweise, wie Du es für richtig hältst.
Lediglich inwiefern multiple exit points auch nur annähernd übersichtlicher sein sollen wie ein single exit point (per definitionem) erschliesst sich mir nicht.
Ist es auch nicht.
Aber der Code, der nötig ist, um in einigen Situationen diesen single exit point anstelle von multi exit point zu erreichen, der ist auch nicht übersichtlicher. Du hast also die Wahl zwischen zwei Varianten, das selbe Ziel zu erreichen, beide Varianten haben sind in gewisser Weise komplizierter als die Andere, nur die Art und Weise der Komplexität unterscheidet sich.
Kein Clean Code vorhanden. Also insofern auch nicht relevant, wenn du meine Argumentation ebenso mit dem Argument "Thema ist Clean Code" abhakst.
Ja, CleanCode war da nicht vorhanden, das stimmt. Die Probleme waren sehr vielfältig, da ist wirklich viel schief gegangen, deshalb war ich auch nach einem Jahr wieder weg.
Worum es mir aber ging, ist, dass man in beiden Fällen "CleanCode vorhanden" vs. "nicht vorhanden" die Argument des jeweils Anderen ausstechen kann. Wenn der Code schön sauber geschrieben ist, kann man unsere beiden Varianten sauber verständlich schreiben, wenn der Code unsauber ist, sind beide Varianten unverständlich.
Mein Punkt, dass ich mich gegen so eine Regel wehre, dass man nur einen exit point haben sollte. So eine Regel kann in manchen Situationen sinnvoll sein, aber eben auch nicht immer, was die ganze Regel ad absurdum führt.
Solche Regeln führen meiner Erfahrung nach leider nicht immer zu besseren Code, sondern häufig auch in die entgegengesetzte Richtung, mit dem Unterschied, dass man dann auf irgendwelche Regeln pochen kann (und es auch tut).
Darf ich das als Fazit für die nächste Schulung verwenden?
Darfst Du.
Ja, das ist ein "gefühltes" oder "schwammiges" Kriterium
Ist es, aber einen besserer Weg zu beschreiben, worauf ich achte, kenne ich nicht :D Die Anzahl Zeilen alleine ist es nämlich nicht, da wäre ich sowieso raus, da ich mit WQHD hier sitze, die meisten Kollegen haben aber nur FullHD.
Wichtig ist eher, wie der Code geschrieben ist, je kürzer der Code, desto mehr Komplexität kann ich auf einen Blick erfassen - und umgekehrt. Ich habe schon Methoden geschrieben, die sind auch bei mehr Zeilen, als auf meinen Monitor passen, mMn. noch klar verständlich (nein, nicht nur ein switch mit 100 cases). Es gab aber auch schon deutlich kleinere Methoden, wo ich lange hin und her überlegt habe, wie ich sie übersichtlicher gestalten kann.
Ich habe auch die Erfahrung gemacht, dass die Augen eine Art "Pattern Matching" machen (ich kenne den fachlich korrekten Begriff nicht), sodass allein die Art und Weise, wie ein Stück Code formatiert ist (Guidelines, z.B. geschweifte Klammer am Ende oder am Anfang der Zeile), extrem viel ausmachen kann. Es gab z.B. letztens eine Methode mit einem inhaltlich ziemlich komplexen Algorithmus, ich habe nur einige LINQ-Aufrufe nacheinander umgebrochen und korrekt eingerückt und hier und da ein paar Leerzeilen eingefügt, plötzlich bedankt sich ein Kollege bei mir, dass er den Code jetzt viel besser versteht.
Das meinte ich mit meinem gefühlten und schwammigen Kriterium.
Mein großer Bremsklotz an dieser Stelle sind immer Controlling und Budgetierung.
Ich glaube beides ist bei uns gar nicht das Problem. Wir sind eine sehr kleine Firma, Projektplanung und viel drum herum machen wir Entwickler, sodass uns niemand hinein grätscht. Das heißt aber auch, dass sehr viel Arbeit auf sehr wenigen Schultern lastet, die natürlich irgendwann nicht mehr hinterher kommen.
Darfst Du.
Danke.
Ich habe auch die Erfahrung gemacht, dass die Augen eine Art "Pattern Matching" machen (ich kenne den fachlich korrekten Begriff nicht), sodass allein die Art und Weise, wie ein Stück Code formatiert ist (Guidelines, z.B. geschweifte Klammer am Ende oder am Anfang der Zeile), extrem viel ausmachen kann.
Vollste Zustimmung. Ich gerate aber auch immer wieder an "Codeextremisten" sämtlicher Lager (auch hier auf GF), für die es Majestätsbeleidigung und Sakrileg darstellt, wenn man Klammern nicht in die "einzige wahre und korrekte Zeile (tm)" stellt. Und solcher Glaubenskriege bin ich mittlerweile einfach nur müde.
Wir sind eine sehr kleine Firma, Projektplanung und viel drum herum machen wir Entwickler, sodass uns niemand hinein grätscht.
Ok, das ist bei uns 180° anders herum: Komplett durchstrukturiert mit Auftrennung der Verantwortlichkeiten. Unsere PO ist zwar recht umgänglich und auch nicht zu knickrig, aber Refactorings sind nicht immer so leicht durchzuboxen, weil die auch irgendwie bezahlt werden müssen. :-/
Naja, das altbekannte Klagelied der professionellen Software-Entwicklung...
Wenigstens haben die BWLer uns nicht reinzureden, das ist immerhin auch schon was wert. :D
Ich gerate aber auch immer wieder an "Codeextremisten" sämtlicher Lager (auch hier auf GF), für die es Majestätsbeleidigung und Sakrileg darstellt, wenn man Klammern nicht in die "einzige wahre und korrekte Zeile (tm)" stellt.
Naja, im Rahmen der jeweiligen Sprache finde ich das aber auch völlig in Ordnung, so zu denken.
Wenn ich im Review von C#-Code sehen, dass jemand die geschweiften Klammern am Ende der Zeile öffnet, geht das direkt zurück und darf korrigiert werden.
Wenn ich im Review von JavaScript-Code sehe, dass jemand die geschweifte Klammer am Anfang der nächsten Zeile öffnet, geht das direkt zurück und darf korrigiert werden.
Naja, außer das Team/die Firma hat sich gemeinsam auf eine andere Schreibweise geeinigt, aber da würde ich dann immer gegen halten, da der meiste Code online oder auch neue Kollegen tendentiell der Schreibweise folgen, die sich in der jeweiligen Community durchgesetzt hat.
Das auf andere Sprachen zu beziehen und "interdisziplinär" einen Glaubenskrieg daraus zu machen, ist aber Quatsch. Mir ist nur wichtig, dass man sich an das hält, was sich weitläufig in der jeweilige Community durchgesetzt hat - bei C# ist das glücklicherweise ziemlich einheitlich.
Komplett durchstrukturiert mit Auftrennung der Verantwortlichkeiten. Unsere PO ist zwar recht umgänglich und auch nicht zu knickrig, aber Refactorings sind nicht immer so leicht durchzuboxen, weil die auch irgendwie bezahlt werden müssen.
Das würde bei uns nicht funktionieren :D Dafür ist da zu viel Bewegung drin. Lustigerweise sind die Kunden Behörden, man sollte ja meinen, da ist alles peinlich genau definiert - ist es nicht :D
PO sind dann am Ende wir, jedes Team kümmert sich um mehrere Projekte und für jedes Projekt ist dann einer PO, der mit den Kunden redet, Dinge entscheidet, alles mögliche plant, etc.
Refactorings sind aber auch ein Problem, die gibt's eigentlich nur, wenn der Kunde sie beauftragt und das zu verkaufen, ist nicht gerade leicht. Ich bin ja schon froh, dass das Update von .NET 7 auf .NET 8 nicht direkt abgeschmettert wurde :/
Ich stimme dir zu. Und auch mich würde die Alternative interessieren.