Coden? Aber bitte mit Style(guide)! // deutsch

Software zu entwickeln umfasst weit mehr Tätigkeiten als lediglich Code in einer Programmiersprache zu schreiben. Ein wesentlicher Punkt ist auch das Befolgen eines Styleguides, der Regeln zum Formatieren und Strukturieren von Code vorgibt. Doch warum ist ein Styleguide so wichtig? Wie sieht ein Styleguide aus? Welche Werkzeuge gibt es? Und wo liegen die Unterschiede zwischen verschiedenen Sprachen?

00:00 – Einleitung
00:47 – Die Relevanz von Whitespace
02:35 – Code formatieren sorgt für Lesbarkeit
03:44 – Richtige und falsche Schreibweisen
04:51 – Eine emotionale Diskussion
06:39 – Nicht alles ist Geschmackssache
07:50 – Gründe für stilistische Entscheidungen
09:52 – Was ist ein Styleguide?
11:05 – Möglichst strikte Regeln
11:57 – Standards: Go und JavaScript im Vergleich
14:06 – Best-Practices überprüfen
15:00 – Warum Styleguides so wichtig sind

────────────────────

Über the native web 🦄

Wir sind ein Beratungs-, Schulungs- und Entwicklungsunternehmen, das sich auf Web- und Cloud-Technologien spezialisiert hat. Wir streben nach intelligenten und eleganten Lösungen für komplexe Probleme, und wir glauben, dass Softwareentwicklung kein Selbstzweck ist. Stattdessen sollte Software tatsächliche Probleme der realen Welt lösen.

Wir glauben, dass native Web- und Cloud-Technologien das Fundament sind, auf dem die Zukunft aufbaut. Unsere Kernkompetenz ist der Entwurf und die Entwicklung verteilter Web- und Cloud-Anwendungen unter Verwendung dieser Technologien in interdisziplinären Teams. Wir entwickeln auch unser eigenes Open-Source-Framework namens wolkenkit. Und wir lieben es, unser Wissen in Schulungen und Workshops, auf Konferenzen und bei Usergroups zu teilen.

────────────────────

Weiterführende Links 🌍

[balazsvarga]

Cooles Video! Mein Motto: "Wenn prettier glücklich ist, bin ich auch glücklich"

Prettier ist schnell und es ist leicht zu konfigurieren. Ich mag es sehr, dass ich mein Code so schreiben kann, wie es mir passt, und am Ende kommt Prettier, und formatiert es so um, wie es im Projekt vorgesehen ist. z.B. double-quote vs single-quote, print-width....usw.

Ausserdem ein grosser Pluspunkt: prettier hat 0 dependency auf npm!

Für mich ist prettier seit Jahren ein absolutes must-have Tool in Javascript Projekten.

[devchannel]

Hammer Video! Seit es eurem Channel gibt, lerne ich so viel mehr über Web/JS. Danke!

[marinaegner]

Danke für das Video!
Ich habe, Dank euch, auch angefangen ESLint in JS zu nutzen. Es war erstmal etwas Arbeit, all die Regeln durchzugehen und den Code zu überarbeiten. Aber es hat sich wahrlich gelohnt! Jetzt hab ich denke ich einen guten Mix aus, persönlichem Geschmack und best practice.
Mittlerweile habe ich eine deutliche bessere Codebase als zuvor.
Danke, für die zahlreichen Tipps!

[yt]

Danke für das Video. Ich bin auf alle Fälle PRO StyleGuide und mag auch strikte Regeln. Wichtig ist IMHO, dass Code gut gelesen werden kann und das hilft dann ungemein.

[ipalfy]

Ich kenne ja die bizarrsten Auseinandersetzungen z.B. Tabs vs Spaces, Einrückungstiefe, etc. ich hab mich einfach an die Standards gehalten, obwohl mir die C#-Klammern schon recht seltsam vorkamen. Seit wir in internationalen Teams zusammenarbeiten, gibts prettier (wenn auch mit 120 Zeichen Breite), eslint default und jedem ist es schlicht egal. Nur Einer liefert immer unformatierten Code ab, weil er vscode nicht mag. Was uns immer wieder amüsiert, aber auch kein Problem ist. Nach der Code Review ist eh alles wieder sauber.

Was mich übrigens immer wieder beeindruckt ist deine präzise Sprache. Keine überflüssigen Anglizismen, keine Wichtigtuerei, kein Wort zu viel dafür jeder Satz auf den Punkt. Nice! ;-)

[AFE-GmdG]

Ich setze schon seit Jahren auf sehr strikte Regeln, welche ich mit ES Lint umgesetzt habe. Diese funktionieren kasse und so brauche ich (aktuell) nicht auf Prettier zu schielen. Ja, immer wenn neue Mitarbeiter kommen muss ich ca. einen Monat mit denen streiten, warum etwas so und nicht anders gemacht werden soll, aber nach danach funktioniert das einfach. (Auch weil sonst die Pull Requests gar nicht akzeptiert würden )

Pro Style Guide + Linter

[christianbaer]

Wir haben tatsächlich 4 Jahre nach bestehen der Code-Basis erst einheitliche und vor allem verbindliche Regeln eingeführt. Das war ein Spaß. Dadurch stehe ich aber wirklich an jeder Datei in der Git-Historie dran. Davor war das aber auch ein Kraut und Rüben. Klammern auf der gleichen vs auf der nächsten Zeile, wilde Mischungen aus Tabs und Spaces (leider haben wir dann Spaces eingeführt; ich wusste es damals nicht besser), if mit und ohne Leerzeichen im Anschluss etc.
Code Reviews sind dadurch aber besser geworden, weil niemand mehr mit einem "Die Einrückung hier, Leerzeile da" ankommen kann und sich nicht um das inhaltliche kümmern muss.
Sowas hatte ich nämlich auch schon in einem anderen Kontext. Da habe ich PRs in einem Kundenprojekt erstellt und eine andere Drittfirma musste das Review vornehmen. Die Code-Basis war relativ neu für mich und ich war mir nicht sicher ob das so die optimale Lösung des Problems war. Die ersten Kommentare waren dann sowas wie "Die Imports müssen alphabetisch sortiert sein." Dann kam erst mal ne Weile nix.
Deshalb geht auch für mich nichts mehr ohne automatischen Linter/Styleguide. Man spart sich so viel unnütze Diskussionen.

[oliverabrahamhamburg]

Bei vielen aufeinander folgenden Zeilen mit Zuweisungen richte ich immer die Gleichheitszeichen untereinander aus, da das für mich viel besser lesbar ist (natürlich nicht von Hand). Was die öffnende geschwungene Klammer angeht, hat es bei mir Jahre gedauert, um mich an beide Varianten zu gewöhnen und quasi "Gelassenheit" zu entwickeln.

[valeridause]

Danke für das Video. Mich würde interessieren, ob jemand welche Motivations- bzw. Anerkennungs-Methoden kennt, wie Entwickler motiviert werden können, über ihren Schatten zu springen und anzufangen, sauber zu codieren? Denn, wenn ich will, dass sie das machen, was sie bis dato nicht gemacht haben, dann muss ich...

[shioli]

Finde codestyle doch in gewisser hinsicht wichtig. ABER ich hatte schon eine Situationen wo zwar die rules vom linter für den meisten code gepasst haben jedoch z.B. für tests überhaupt gar nicht. Hatte ein typescript projekt entwickelt für einen datamatrix reader (off the shelf reader wie z.b. xzing haben bei dem fall einfach nicht ansatzweise funktioniert für kleine graue eingestanzte punkte auf schwarzem blech). Und da ist mir der linter dann doch eher aufm zeiger gegangen wenn der dann will dass ich 2d bit arrays nicht so formartiere wie ein grid, sondern dass ich jeden eintrag in eine eigene zeile schreibe und dann aus nem 16x16 code statt 16 zeilen 256 zeilen werden beim "auto formartieren". Lesbarkeit ist manchmal eben nicht konsistent mit einer einfachen regel beschreibbar. Daher meiner meinung nach ja code style gut. Aber es muss möglichkeit geben ausnahmen zu deffinieren (eslintignore comments). An sonsten habe ich lieber einen nicht so strikten linter. Im Falle von eslint gräbt man sich da halt sein eigenes grab, bei go ähh je nachdem. Vielleicht ist es toll. Vielleicht gibt es auch solche fälle wo du dann an die decke gehst was die da mit deinem code anstellen ohne dass du was dazu zu sagen hast. Kann ich nichts dazu sagen. Hatte die sprache noch nie in verwendung.

[markusschmidt]

Danke für dieses Video! Aber nun mal das Gegenbeispiel aus der Freien Welt: Principal Devs die per Hand Java Code formatieren und in jedem Modul herrscht eine andere Formatierung vor :-) Das führt zu sehr viel "Spaß" :-) So genug zum lachen gehabt :-) Weiter formatieren

[iRoybot]

Toxische Diskussionen über die richtige Formatierung braucht kein Mensch, und gerade Neulinge fühlen sich da schnell bevormundet. Der Satz "man sollte eigentlich dem Code nicht ansehen wer ihn geschrieben hat" bringt es auf den Punkt. Also linter, fixer, ecs, sniffer etc einmal konfigurieren, in die build pipeline packen und mit nem Auto commit gerade biegen. Bei zu hoher Fehlerrate den build abbrechen und gut. Umso besser wenn der style guide aus dem cms oder dem framework kommt, dann ist nicht der Senior schuld der die build pipeline aufsetzt. Meine 2 Cent aus der php perspektive

Ps: super Videos. Grossen Respekt. Weiter so.

[dirkj.]

Es wird meiner Meinung nach viel zu viel Augenmerk auf die äußere Form des Codes gelegt. Eine strikte Formatierung macht es aus meiner Sicht nicht besser, wenn der Code an sich nicht gut ist. Wichtiger ist statische Codeanalyse, effiziente Routinen, Verwendung der richtigen APIs, usw.

(Meine Erfahrungen beziehen sich hauptsächlich auf Java, wo es ja keine verbindlichen Vorgaben zur Formatierung gibt)

Und wie kann Code formatiert sein dass man tatsächlich Probleme hat ihn zu verstehen!? Das ist mir extrem selten untergekommen. Nach Jahren Erfahrung und diversem Code aus verschiedenen Projekten kann ich nicht sagen, dass es einen großen Unterschied macht wo wieviele Leerzeichen zwischen den Operatoren stehen oder sogar auf welcher Zeile die geschweifte Klammer!

Strikte Styleguides sind immer ein Kompromiss und regeln Dinge bei denen verschiedene Entwickler unterschiedliche Präferenzen haben. Insofern drückt derjenige der die Entscheidung trifft "wie Code auszusehen hat", den anderen seine Meinung auf. Denn es werden ja eben nicht überwiegend Dinge festgelegt die den entstehenden Code beeinflussen, sondern vielfach Geschmacksfragen.

Der Idealfall wäre, wenn jeder Entwickler den ausgecheckten Code in seiner eigenen Formatierung sehen könnte. Dazu müssten aber die Vergleichstools deutlich flexibler funktionieren. Ein Vergleich müsste auf Ebene von Sprachelementen ablaufen und nicht auf Zeichenbasis, weil es für den fertigen Code eben völlig irrelevant ist auf welcher Zeile die Klammer steht.

[tuggspeedman]

Geschweifte Klammer in der neuen Zeile?!?

Absolutely babaric...!!!

[valeridause]

Entwickler sind mehr Künstler als Ingenieure, daher kommt ihr Chaos im Kopf, im Verhalten, auf dem Tisch, in den Datenbank-Modellen und auch im Code. Das lässt sich mit den angesprochenen Tools und Styleguides zu mind. im Code ein wenig vermeiden, doch grundsätzlich - das gehört einfach dazu. Leider.

Früher als Entwickler mehr Ingenieure als Künstler waren - da haben sie immer Hemden und Krawatten, sogar Fliegen getragen und z.B. bei IBM die Styleguides für die Form und Farbe der Anzüge, Hosen und Socken existierten.

[michaelmueller]

* Geschwungene Klammern immer in die nächste Zeile und öffnende/schließende Klammer immer auf derselben Einrückungsebene-> damit man sofort weiß, was in welchem scope steht. Außerdem sehr sinnvoll, wenn man 'pro Zeile bezahlt wird'
* Für jedes Funktionsargument eine neue Zeile -> viel übersichtlicher

Für Rust wäre das

max_width = 150
comment_width = 150

new_line_style = "Unix"
brace_style="AlwaysNextLine"

version="Two"
fn_args_layout="Vertical"

[yutubl]

Dies ist ein Randthema mit eher sozialem als technischem Aspekt. Ich halte Coding-Style weder für genauso wichtig noch wichtiger als Codekorrektheit. Wie Du bereits erwähntest wirkt sich die Formatierung des verwendeten Coding-Styles sich ja nicht auf die Korrektheit des Codes aus. Codekorrektheit hingegen ist ein wichtiges Thema.
Mich erschreckt ehrlich gesagt Dein Beispiel der wiederkehrenden unnötigen Umformatierungsänderungen die im (schlecht konfigurierten) Diff-Tool ggf. die relevanten Änderungen von überflüssig vielen Formatierungsänderungen untergehen lassen.

Es geht vielmehr darum welcher Coding-Style akzeptiert wird und womöglich Zusammenarbeit erleichtert oder erschwert. Und die Zusammenarbeit verhindern kann kein (noch so unpassender) Coding-Style, wohl aber wucherndes von Programmierern bzw. automatisch formatierende Tools mit unterschiedlichem Formatierungskonfiguration.
Die Frage ist also ob dieser von den relevanten Leuten und Tools akzeptiert wird.
Für episch nie endende sich über derartige Randthemen stark ereifernde Programmierer bringe ich begrenzte Geduld mit. Solch menschliches Verhalten erscheint mir eher nach künstlichem bzw. vorgeschobenem stellvertretendem Streit, also wenn diejenigen selbst verdeckten Frust hier ausleben oder jemand anderen mobben bzw. weg ekeln wollen.
Dann können akzeptierte und gelebte Codingstyleguides zur sozialen Befriedung beitragen.

[AndreasKempe]

Es ist ehrlich gesagt ein wenig erschreckend, dass du ernsthaft 6 Monate so ein hin und her mitmachst an statt dich das erste mal, wenn du feststellst dass ihr noch gar keine einheitliche Richtlinie definiert habt für euer Projekt, es zur Diskussion bringst und ihr euch auf einen gemeinsamen Stil einigt. Dass ihr da ständig tausende Dateien vom anderen immer wieder anpassen. Wahnsinn. Selbst wenn es automatisch läuft. Das klingt so extrem nach Schildbürgertum.

Meiner Ansicht nach ist in jeder Firma ein einheitlicher Stil pro Sprache notwendig und unabdingbar. Zum einen um die Lesbarkeit zu erleichtern und neuen Mitarbeitern das Einarbeiten leichter zu machen, zum anderen um auch das Bewusstsein für eine saubere Codestruktur zu schulen bzw. zu entwickeln. Vielen ist gar nicht klar wie schlecht sie programmieren, weil der Code anderer völlig anders formatiert und damit gar nicht vergleichbar ist.

Bei der optischen Absetzung von logisch zusammenhängenden Blöcken bin ich völlig bei dir und finde den Vergleich auch sehr treffend. Ich sage immer das wir an Büchern arbeiten als Autoren. Dem entsprechend müssen wir auch fürs Auge arbeiten. Absätze herausbilden und Zusammenhänge optisch hervor heben. Oft sieht man an dieser Notwendigkeit schon dass die Funktion an sich viel zu umfangreich ist und macht sich selbst schon deutlich wo man die eventuell splitten kann. Einfach nur in dem man ein wenig Ästhetik walten lässt.