Code Guidelines / Kodierrichtlinien - Clean Code nach Anleitung

[@DavidTielke]

Schreibt gerne mal in die Kommentare, wie Ihr das mit Code Guidelines seht. Verwendet Ihr bereits Code Guidelines? Und wenn ja, werden sie akzeptiert und wlchen Umfang haben Sie? Ich bin gespannt... :) Und solltet ihr den Kanal noch *nicht abonniert* haben, macht das doch bitte :)

[@DavidTielke]

Wahahaha.... Guter Einwand, genau mein Humor! :D Gruß David

[@Aalii6]

interessantes Thema, danke!

[@DavidTielke]

Sehr gerne Ali, Gruß David

[@andrekirst]

Ich finde Coding Guidelines extremst wichtig. Zum einen geht es ja um das gleiche Verständnis con Quellcode. Wenn ich z.B. folgendes lese: "variable = Text;", weiß ich, dass links eine Variable innerhalb einer Methode ist und rechts eine Eigenschaft. Ohne zu der Definition desjeweiligen zu gehen. Der andere Punkt ist, wenn es alle anders machen und man immer hinterher ist, seine eigenen Richtlinien zu schaffen bzw. zu übernehmen, hast du unnötige Codeänderungen und somit mehr Aufwand bei einem Review. Am Ende macht der Code das gleiche, aber die Änderung an den Richtlinien hält auf. Zum Glück gibt es Resharper und .editorconfig, die da ein wenig Einhalt gebieten, was ich gut finde.

[@DavidTielke]

Hallo André, bin total bei Dir. Resharper bzw. die anderen Editor-Tools sind total gut, allerdings würde ich mir wünschen das man dort etwas mehr Anpassbarkeit betreiben könnte. Meist kann ich eine Regel entweder nehmen oder raus lassen. Das hat meist auch einen Einfluss auf die gewählten Regeln, also für mich nicht so optimal. Wie lang sind Eure Richtlinien? Gruß David

[@Marco_M84]

Hallo David, für unser Entwicklungsteam ein sehr aktuelles Thema. Wir sind bei uns gerade dran unsere Code Guidelines nach langem einmal wieder zu überarbeiten und für alle verständlich zu machen. Es wurde leider nicht konsequent verfolgt und somit haben wir jetzt verschiedene Stile in unseren zwei seit über 10 Jahren gewachsenen Produkten. Ich werde morgen auch noch einmal intern das Thema mit Button vs. btn und Textbox vs. txt anbringen. Wie ist deine Meinung zu den Abkürzungen bei Controls? Lieber die Klassen komplett ausschreiben und längere Variablen Namen riskieren oder kurz und ggf. nicht so schnell lesbar, aber „übersichtlicher“ gestalten? Dann haben wir bei uns dem Punkt Felderprefix. Früher wurde viel mit „m_fieldName“, dann mit „_fieldName“ und jetzt mit „this.fieldName“ umgesetzt (Wenn ich mich nicht irre auch eine Empfehlung von Microsoft). Ich bin aktuell immer noch ein Fan von „_fieldName“ da es übersichtlicher (kürzer) und schneller als ein "this.fieldName" zu tippen ist. Wie ist hier deine Meinung? Beste Grüße und vielen Dank für deinen Einsatz Marco

[@DavidTielke]

Hallo Marco, ja, da hast Du total recht, das ist die größte Gefahr bei den Code Guidelines. Nur das Dokument alleine reicht nicht, es muss auch allen klar sein, das es eine Verpflichtung ist, die auch auf EInhaltung geprüft werden sollte. Was deine Controls angeht, bei Klassennamen (z.B. UserControls) würde ich normale Klassennamen verwenden. Wenn es jetzt und die Verwendung im Quellcode geht (also die Feldnamen von Controls), verwende ich auch txt, btn & Co. Weil bei Technologien wie beispielsweise Web- oder Windows-Forms gibt es keine adäquate Nöglichkeit der Modularisierung, d.h. die Klassen werden meist sehr groß und haben somit massenweise Controls und damit Felder. Daher finde ich es aus Sicht der Analysierbarkeit wichtig, mit solchen "Hilfsmitteln" da für Übersichtlichkeit zu sorgen. Für normale Felder nehmen ich immer den führenden Unterstrich, also _fieldName, weil so im Quellcode direkt ersichtlich ist, das hier der Klassenzustand geändert wird. Wie lang sind Eure Richtlinien? Gruß David

[@Marco_M84]

@@DavidTielke danke für das Feedback. Wir sind aktuell bei 20 Seiten aber noch lange nicht fertig :-)

[@DavidTielke]

Gerne, ja 20 Seiten ist noch Ausbaufähig :) Viel Erfolg! Gruß David

[@christofgentzmer5015]

Es gibt doch ein offizielles Buch (für .net) dazu: Framework Design Guidelines von Anders Heilsberg. Das "goldene Buch" für uns.

[@DagarCoH]

Danke für das Video. Werde ich bei uns dann auch mal anstoßen, da das Software-Team sich wohl bald verdoppeln wird (von 1 auf 2 Entwickler). Kleine Anmerkung: beim englischen "debt" ist das b stumm

[@stefanalpers7415]

Ein Thema, dessen Umsetzung stark von der Einstellung und Bereitschaft der Kollegen abhängt, sich kontinuierlich weiterzubilden und neue Dinge nach kritischer Begutachtung zu verwenden oder eben nicht. Man könnte Schleifen ja immer noch mit GOTO machen aber wahrscheinlich jeder sieht ein, dass es heute bessere Sprachkonstrukte gibt.

[@heischono4917]

Ich habe vor einiger Zeit selbst Kodierrichtlinien erstellt, die für unser kleines 2-Leute-Team gelten sollen. Dann habe ich meinen Chef (bei uns wörtlich übersetzt "Fachverantwortlicher") darauf angesprochen, wie er es denn hält mit solchen Richtlinien. Seine Reaktion hat mich überrascht, er sieht darin keinen Sinn weil sowieso jeder macht was er will und die Richtlinien als unnötige Einschränkung empfunden werden. Da liegt noch ne Menge Arbeit vor uns! Ich werde im neuen Jahr mal direkt zum Big Boss gehen, und ihm erklären worum es geht. Er will schließlich alle Entwickler überall einsetzen können, da sollten Kodierrichtlinien absolute Top-Priorität haben. Andererseits kann man ja mit diesen Richtlinien kein schnelles Geld auf direktem Wege machen ... Mal sehen wie das ausgeht. VG, Heiko

[@Wxyyyftw]

Und wie ging es aus? Bin in einer ähnlichen Situation.

[@heischono4917]

@@Wxyyyftw da uns Corona ganz schön zugesetzt hat, und ich eine Weile auch krank war, hab ich das alles ruhen lassen. Die Norweger kann man eh schwerlich umerziehen, ich mache es jetzt einfach so, dass ich versuche, mich mit den Teammitgliedern auf die wichtigsten Sachen zu einigen. Der erwähnte Big Boss hat derzeit viel zu viel anderes am Hals, als dass er Kodierrichtlinien jetzt in den Fokus setzen würde... 😉

[@MyParaGuide]

Furchtbar. Mit Dir möchte ich nicht zusammenarbeiten.

[@heischono4917]

@@MyParaGuide wieso genau? Und woher kennst du mich so gut?

[@MyParaGuide]

@@heischono4917 Weil ich niemanden brauche, um für mich Codier-Richtlinien zu erstellen. Du möchtest auch nicht unter "meinen" Codier-Richtlinien arbeiten, glaub mir. So etwas bespricht man im Team, fügt es dem Working Agreement hinzu und rennt nicht heulend zum Big Boss, nur weil man sich nicht durchsetzen kann. Ich kenne Dich so gut, weil ich seit über 20 Jahren berufstätig bin. Und in fast jedem Team, egal ob ich Entwickler, Projektleiter oder Scrum Master war, gab es Mitglieder wie Dich. Aber Du kannst Dich ja ändern. Nimm´s deshalb persönlich.

[@hubertfuchs2237]

Bei uns sind die Coderichtlinien schon etwas älter(ein paar Punkte, wie man vor 20 Jahres Software entwickelt hat) und es wird nicht mehr alles erst genommen was darin steht. Ich habe erfolgreich ein Mindmap zu diesem Video erstellt... das ist wirklich sehr hilfreich um sich noch mehr wichtige und hilfreiche Punkte zu merken. Mir ist auch gleich ein Fehler aufgefallen :)) bei "Wo gibt es die Vo_r_lagen". Da fehlt das "r" ;-)) Nützlich für mich fand ich auch den Tipp die Nummer der Regel ggf. in der Code Review anzugeben. Danke.

[@andreweinert8725]

Der schlimmste Kommentar zum Thema Kodierrichtlinien: "Ich mache das seit 15 Jahren so, warum soll ich mich jetzt ändern!" Ansonsten werde ich deine Anmerkungen mal in meine einfließen lassen.

[@DavidTielke]

Das kenne ich leider Andre - Versuch ihm zu erklären, dass es nicht darum geht, das er anders programmieren soll, sondern alle einheitlich - vielleicht sogar wie er :) Viel Glück!

[@andreweinert8725]

@@DavidTielke Manche Menschen können oder wollen sich nicht Ändern. Zumindest mein jetziges Team sieht die Notwendigkeit von Kodierrichtlinien ein.

[@DavidTielke]

Das stimmt, aber meist ist das eher die "Angst" das jemand mit der eigenen Arbeit nicht zufrieden ist, wenn man es transparent macht und das Ziel von "gemeinsamen Code" aufzeigt, lassen die sich oftmals überzeugen. Oft kann man ja auch von den erfahrenen sehr profitieren, wenn es um die Erstellung der Richtlinie geht.

[@peacemakerle]

Coding Guidelines sind gut und wichtig. Es muss nur verhindert werden, dass Architekten da weltfremden Dogmatismus betreiben. Z.B. wenn sie verlangen, dass ausnahmslos jede Funktion kommentiert werden müsste. Oder wenn einer z.B. in Java Namenskonventionen mit verbindlichen Unterstrichen vorschreibt, obwohl das in der Sprache gar keinen Sinn macht.

[@Eratosthenes0815]

Antwort in Kurz: LAAANG und Nö!