Da eigentlich auch so als Best Practice angesehen wird, was ich
aber eiskalt ignorieren würde, weil Nein das.
Das unterstütze ich nicht. Coding Boys, Dein Podcast rund
um Softwareentwicklung und aktueller Technews.
Herzlich Willkommen. Was?
Ja, herzlich Willkommen zur
neuen Folge des Coaching Bodys Podcasts.
Schön, dass du wieder eingeschaltet hast.
Natürlich wieder mal mit dabei, meine Wenigkeit, der Tino und
natürlich auch der fantastische Fabi.
Herzlich Willkommen Fabi zur neuen Podcast Folge.
Einen wunderschönen guten Tag, Tino.
Wie geht es dir? Mir geht es gut, mir geht es
fantastisch, ich. Alles in Ordnung soweit.
Ich hab gute Laune, ich bin irgendwie.
Voll aufgekratzt. Ich weiß nicht.
Warum aber? Läuft es, läuft einfach schön.
Wirkst gar nicht so aufgekratzt da.
Ich muss doch fragen, was geht ab, fabi?
Was geht ab? Meine Signaturfrage muss kommen.
Was geht ab, was geht denn ab? Ja, wir haben ja schon im
Vorfeld ein bisschen gequatscht, nur zu zweit, nicht zu dritt.
Die Utorrent hast ja jetzt eben gerade erst eingeschaltet
logischerweise, und deswegen haben wir schon mal n bisschen
zu zweit über n Thema gesprochen.
Und bevor ich das jetzt aber mal vorstelle, möchte ich noch auf
eine etwas ältere Folge eingehen.
Und zwar hatten wir ja die Folge, das müsste jetzt auch
schon n paar Wöchlein her sein. Eine Mythos oder Faktfolge
gemacht zum Thema, dass es keine Frauen in der
Softwareentwicklung gibt und haben da mal drüber gesprochen,
ob das n Mythos ist oder n Fakt und sind zu dem Schluss
gekommen, dass es leider noch n bisschen mehr Fakt als n
bisschen mehr doch n bisschen mehr Fakt als Mythos ist.
So rum. Zumindest aus unserer Sicht.
Aus unserer Sicht aber sich die Tendenz abzeichnet, dass doch
die Frauenquote da steigt über die Jahre, was natürlich eine
super schöne Entwicklung ist. Und hatten ja einen Aufruf.
Gestartet in der Folge, dass sich doch bitte aus unserer
Community alle Frauen melden sollen.
Die. In der Softwareentwicklung oder
zumindestens Berührungspunkte damit haben dort in dem Bereich
unterwegs sind und mal ihre Erfahrungen schildern oder was
sie vielleicht glauben. Warum es so sein könnte, dass es
halt immer noch quasi. Mehr Männer als Frauen gibt.
Und da haben wir ja n paar Rückmeldungen bekommen und eine
fanden wir ganz besonders cool, da haben wir ne Mail bekommen.
Magst du vielleicht mal davon berichten?
Ja, sehr gerne. Susanne hat uns nämlich
geschrieben und hat uns so n bisschen ihre Geschichte
erzählt, wie sie zum Beispiel in die Softwareentwicklung gekommen
ist und hat uns auch so n bisschen ja mitgeteilt oder so
Erfahrung geschildert, was wir ja auch, was viele ja irgendwie
kennen, so leider Gottes ne, dass zum Beispiel so, dass die
als Mädchen auch nicht so viel mit Computern zu tun hatte als
Kind und das zum Beispiel der Informatikunterricht in der
Schule halt langweilig war, das hast du ja auch schon
geschildert, Tino. Und sie war auf jeden Fall gut
in Mathe und Bio und konnte in ihrer Schule auch in so ne
Klasse gehen, wo extra so eine extra naturwissenschaftliche
Klasse und auch da waren relativ wenig Mädchen vertreten.
Was sie geschildert hatte und nach dem Abi hat sie dann
Biomathematik studiert. Interessanter Studiengang auf
jeden Fall, macht aber Sinn von dem, was ihre Stärken waren und
hat dann aber auch mitgekriegt, dass dort in diesem Studiengang
wahrscheinlich meinte sie, durch die Biologie mehr Frauen als
Männer waren in diesem Studiengang vertreten.
Und in diesem Studiengang hatte sie das erste Mal
Berührungspunkte mit der Informatik.
Vor allem, weil sie auch n sehr guten Juniorprofessor hatte, der
das wohl sehr schmackhaft gemacht hat.
Dieses Thema, was natürlich total cool ist.
Und was mir auch wieder zeigt, dass es wichtig ist, das Ganze
auch irgendwie cool zu machen, weil wie gesagt langweiliger
Informatikunterricht bedeutet, interessiert mich nicht, aber
wenn es dann doch irgendwie cool aufbereitet ist, dann macht das
irgendwie. Sinn?
Ja, das deckt sich ja dann komplett mit den Punkten, die
wir da so genannt hatten, also dass sie quasi in der Schulzeit
die gleichen Erfahrungen gemacht hat.
Und dann aber halt diese eine Juniorprof schon dafür sorgen
kann, dass man doch Interesse an diesem Thema gewinnt quasi und
merkt, Hey, das ist doch vielleicht doch was, was mir
Spaß machen könnte und vielleicht vertiefe ich mich
mal. Denn doch in dem Bereich, zum
Beispiel Softwareentwicklung und.
Das hat sie auch gemacht im Master, dass sie das Halt sehr
Informatik lastig dann ausgelegt hat.
Ja, und sicherlich, weil da so dieser Grundstein gelegt wurde.
So wie ich das verstanden hatte, und das finde ich halt mega cool
und man muss natürlich sagen, dass so Naturwissenschaften.
Welche Studiengänge, oft auch ne Schnittstelle haben, also dass
es oftmals Bereiche gibt, wo die Informatik eine Rolle spielt und
man da natürlich dann relativ schnell die Tür öffnen kann, um
mal in diesen Bereich reinzuschauen.
Genau, und das ist halt da natürlich ne super Gelegenheit
gewesen und ich find es auch sehr cool Suse, falls du diese
Folge hörst, dass du das auch gemacht hast, fand ich auf jeden
Fall auch sehr beeindruckend. Ja, mega cool und auf jeden Fall
hat sie dann auch noch geschrieben, dass sie.
Halt eben sich so n bisschen als halb Quereinsteigerin sieht,
weil sie halt eben nicht Informatik studiert hat, aber
trotzdem halt sehr gerne danach in die Softwareentwicklung gehen
wollte und dann auch noch n dreimonatigen Intensivkurs
gemacht hat und dann sozusagen mit ihrem.
Studium mit diesem informatiklastigen Studium was
sie sich selbst gewählt hat Plus zum Intensivkurs ist auch dann
geschafft. Hat den Einstieg in die
Softwareentwicklung zu machen. Ja und jetzt schon seit mehr als
8 Jahren als Softwareentwicklerin arbeitet.
Und so viel erstmal zu Ihrer Geschichte.
Was ich aber sehr interessant fand und was wir beide ja sehr
interessant fanden, war ja der Punkt, dass nach ihrer Schätzung
der Frauenanteil im Softwarebereich in der Firma, in
der sie arbeitet, bei ungefähr 40% liegt und das ist halt echt
schon relativ hoch, weil wir haben ja auch gesagt, dass wir
das so von unserer Arbeit gar nicht so kennen, es du aber auch
zum Beispiel einen Freund hast, der ja auch in der Firma
arbeitet, wo auch einige Softwareentwicklerinnen
arbeiten, was natürlich cool ist, aber ein Anteil von 40% ist
natürlich schon echt stark. Und das ist natürlich auf jeden
Fall noch mal so ein bisschen so ein kleiner, so ein kleines
Gegenbeispiel zu dem, dass nur Männer in der
Softwareentwicklung sind. Quasi ein Beispiel dafür, dass
es halt eben vielleicht nicht überall.
Sozusagen so ist, dass es keine Frauen gibt, sondern dass es
eher ein Mythos als ein Fakt ist.
Und das ist natürlich cool, also sozusagen genau dieses Beispiel
von Susanne zu. Hören vielleicht.
Ist da einfach unsere Umgebung, in der wir arbeiten?
Vielleicht ja auch noch n bisschen hinterher?
Es kann ja auch sein, ne, dass es so in anderen Firmen da schon
besser aufgeteilt ist, was ja einfach nur zu begrüßen wäre.
Auf jeden Fall ein super Beispiel, dass es, dass es sie
gibt, die Softwareentwicklerin, und es hat uns sehr gefreut,
Suse, vielen, vielen Dank noch mal für die Nachricht und dass
wir auch die Erlaubnis von dir bekommen haben, dass hier im
Podcast zu teilen, weil vielleicht motiviert das jetzt
auch die eine oder andere höhere.
Doch weiterzumachen oder damit anzufangen, auch über n
Quereinstieg nachzudenken oder vielleicht auch während des
Abiturs sich zu denken, hey, so n Informatikstudium könnte doch
ganz cool sein. Genau.
Und wenn du, liebe Zuhörerin, dir jetzt sagst, ach Mensch, das
ist ja echt spannend. Bei mir ist das tatsächlich auch
so wie bei Suse. Dann schreibt uns auch einfach
mal über die Podcast Mail oder wenn es zum Beispiel.
Auch. Wie bei uns halt auch, sag ich
mal. In der Ferne liegt das irgendwie
der Frauenanteil und der Männeranteil quasi ausgeglichen
sind. Dann schreibt uns auch mal wie
es bei euch ist, wenn ihr da Lust drauf habt.
Die Podcast Mail ist auf jeden Fall in den Shownotes verlinkt.
Ganz genau. Und ich würde sagen, dann können
wir jetzt ja zu dem. Thema der heutigen Folge kommen
mir ist gerade das Wort Thema nicht eingefallen.
Schwieriges Wort. Und zwar Fabi wollen wir heute
ja noch mal. Eine Folge zum Thema Cleancode
machen. Das heißt, unsere Reihe
fortführen. Wir haben ja ein gutes Feedback
dazu bekommen und finden ja das Thema selbst auch sehr wichtig
und spannend und deswegen drehen wir das Rad weiter.
Eine neue Folge cleancode und zwar soll es heute in der ist
das jetzt schon die 6. Folge Oh mein Gott nagel mich
nicht drauf fest, aber wir haben auf jeden Fall schon einige dazu
gemacht, fünft oder sechst. Ne und auf jeden Fall geht es
heute um das Thema. Das klingt erstmal n bisschen
trivial, aber ich denke, dass wir da auch einige Punkte zu
finden werden. Halt dich fest, ich halt mich
Formatierung, auch wenn fast schon jetzt hab ich es gesagt,
bevor du dich festgefallen festgabe bevor du dich
festgehalten hast. Genau das Thema ist Formatierung
Code Formatierung, das ganze Projekt, die Formatierung
allgemein und. Das ist ein Thema, da scheinen
sich auch die Geister, gibt es unterschiedliche Ansichten,
unterschiedliche Vorlieben, wie man was formatiert.
Ich möchte jetzt ja auch nicht irgendwie darauf kommen, was
richtig und falsch ist. Aber vielleicht, dass man mal so
n bisschen herauskristallisiert, was n guter Stil ist und was er
kein guter Stil ist. Also ich finde jetzt nicht um
mal so n kleinen so n kleines Vorwort da mal zu geben.
Ich finde nicht, dass es ein absolut richtig und ein absolut
falsch gibt, also es ist halt wirklich immer so ein bisschen
definitionssache am Ende auch, aber ich glaube, dass man da
trotzdem jetzt so ein paar Best Practices mit auf den Weg geben
kann für. Die sich vielleicht gerade am
Anfang der Reise befinden, also der Reise zum Softwareentwickler
softwareentwicklerin, dass man darauf auf jeden Fall n paar
gute Punkte mitgeben kann. Aber was man jetzt so fand.
Ja, aber Tino jetzt mal ernsthaft.
Also Formatierung von Code ist doch völlig egal, oder?
Und das war es auch schon mit der Folge.
Das war unser unsere Best Practice, macht was ihr.
Wollt, Hauptsache ihr. Schaltet nächstes Mal wieder
ein. Nein, ganz so einfach ist es
natürlich nicht. Ja, finde ich auch.
Also ich, ich finde das ist das das das Thema klingt erstmal
echt irgendwie trivial und auch sehr.
Schnell vernachlässigbar, dass man sich so denkt.
So, ja komm, es gibt wirklich Wichtigeres als eine
Formatierung vom Code. Aber ich kann auf jeden Fall
gerne dann auch vielleicht n bisschen später auch noch mal n
in in in Beispiel nennen. Was ich zum Beispiel auch
wirklich sag, jetzt mal am eigenen Leib erlebt habe im
punkto Code Formatierung, was wirklich unglaublich nervig sein
kann. Und aber wir können ja erstmal
mit mit den mit n paar Low hanging Fruits anfangen.
Wenn es jetzt zum Beispiel um Code Formatierung geht, weil du
hast ja gesagt es geht n bisschen darum, dass man sich
auch im Team dass man ne Einheitlichkeit vom Code hat,
dass man quasi auch irgendwie Absprachen hat, woran man sich
vielleicht hält und. Was wäre denn vielleicht so das
erste, was dir einfällt, wenn es um Formatierung geht?
Die. Die dir jetzt als erstes so in
den Kopf kommt. Ja, also das erste wäre für
mich, ich bringe jetzt mal n Beispiel und dann können wir ja
sagen was daraus resultiert. Ne weil ich würd halt gern noch
so n paar Punkte herauskristallisieren, warum das
denn wichtig ist. Ne und so.
Absolute Basics und da machen sich viele wahrscheinlich auch
keine Gedanken mehr heutzutage drum, weil ja auch so moderne
Ideis einem das sehr viel abnehmen.
Sind für mich halt so diese horizontale und vertikale
Formatierung von Code und was ich damit meine ist zb wie lang
eine Zeile ist eine Codezeile. Und oder halt auch die
klassische Einrückung von Code, um quasi gültigkeitsbereiche
besser. Grafisch darzustellen nenne ich
es mal. Was ich interessant finde ist,
wenn du jetzt von der. Was heißt horizontalen
Begrenzung sprichst, wenn man sich mal genau anguckt und mal
so ne IDE schnappt und da mal sag ich jetzt mal genauer
hinguckt, dann ist es vielleicht für Neuankömmlinge in der.
Softwareentwicklung wenn man eine ID hat vielleicht.
Komisch, dass in dem Editor irgendwo auf der Seite n
vertikaler Strich ist. Der ist dann meistens eher
rechts irgendwo an der Seite und vielleicht eventuell weiß man
nicht genau was soll denn das genau sein?
Ne, also ich hatte ganz am Anfang dachte ich mir auch so ja
okay cool keine Ahnung also ich glaube damals gab's gefühlt
sowas noch gar nicht, irgendwann kam das dann und das ist halt
zum Beispiel auch sowas wie vielleicht so eine
Voreinstellung von der IDE die sagt Okay deine deine
Blattbreite in Anführungsstrichen.
Ist jetzt hier vorbei und du solltest nicht darüber
schreiben. Also das ist ja glaube ich das,
was du als ein Beispiel meintest, nur dass man sich das
vielleicht ein bisschen besser vorstellen kann, oder wenn man
jetzt als Neuankömmling sozusagen mal eine IDE aufmacht,
also so eine Entwicklungsumgebung und sich
denkt, ach guck mal, Tatsache, da ist ja wirklich so ein
Strich, jetzt weiß ich, was der zu bedeuten hat.
Also dazu muss man natürlich sagen, also.
Der Strich ist dafür da, dass du halt gedanklich siehst, bis wo.
Und das meinte ich halt auch mit IDS nehmen dir die Arbeit ab,
weil es halt ne gewisse Autoformatierung nach Regeln
gibt und die ID würde halt ab diesem Strich halt n
Zeilenumbruch machen und sinnvoll mit gewisser Logik
halten, Zeilenumbruch nicht einfach nur an der Stelle quasi
abschneiden, weil das wäre ja dann wahrscheinlich würde das
ein Syntaxfehler führen, aber es wird halt ein logischer
Zeilenumbruch eingebaut, das Ganze ist aber natürlich auch
ein bisschen historisch bedingt also.
Es geht ja darum vor allem, dass in früheren Jahren man gar nicht
so eine hohe Auflösung hatte auf seinem Bildschirm und
dementsprechend nicht so viel Pixel zur Verfügung wie
heutzutage, wie beispielsweise bei einem 4 K Monitor.
Da kannst du natürlich ordentlich in die Breite gehen
und kannst alles noch gut lesen und erkennen, aber wenn man sich
jetzt mal vorstellt, man hat nicht so viel zu sehen, dann
willst du ja auch nicht anfangen rum zu scrollen, dass du immer
von links nach rechts scrollen musst um dein Code lesen zu
können, weil das ist nämlich jetzt so der erste wichtige
Punkt, weswegen? Formatierung ne Rolle spielt ist
einfach die die Lesbarkeit ne gute Lesbarkeit des Codes
fördert natürlich auch ne schnellere Arbeitsweise und da
ist das so traditionell auch her sag ich mal beziehungsweise.
Es spielt immer noch ne Rolle, weil du würdest es ja immer noch
schaffen, wenn du möchtest. So lange Code seien zu
schreiben, dass da auch deine Auflösung nicht mehr ausreicht.
Und du wieder scrollen musst. Und das Ganze natürlich wieder
zu einer unglaublich schlechten Lesbarkeit führt.
Bis hinzu Sprachen wie beispielsweise Java, wo du
einfach alle Zeilen hintereinander hängst.
Du musst die ja nicht in neue Zeilen packen.
Also jedes Codesegment sage ich mal, jede Anweisung, und das ist
natürlich ein schlechter Stil, dann ist es kann man gerne
machen, aber es wäre für mich jetzt ein schlechter Stil und
nicht best practice, das zu tun und deswegen achtet man halt zum
Beispiel auf diese Zeilenlänge. Und in der Vertikalen ist halt
ein sehr, sehr wichtiger Punkt dieser Einrückung.
Was ich schon meinte. Klassisch, wenn du eine Funktion
definierst, dass dann der Code der Funktion quasi genau um 1
nach rechts geschiftet wird, um ein Tab meistens.
Das ist ja auch immer so eine Definitionssache.
Was ist ein Tab, sind es 2 Leerzeilen Zeichen?
Oder 4 auch wieder Geschmackssache.
Ich persönlich bin Fan von 4 muss ich sagen, das ist aber
auch mal anmerken, ist aber. Witzigerweise auch n Unterschied
ich also mittlerweile sind die IDS darauf eingestellt, dass
sozusagen für ein Tab Leerzeichen verwendet werden.
Es gab aber mal ne Zeit. Ist jetzt auch nicht so lange
her, weil es klingt immer so, wie ja damals vor 100 Jahren.
Es ist nicht so lange her, aber da gab es halt auch eben bei
IDES den Fall, dass zum Beispiel N tappen Tab war.
Was durchaus auch n Unterschied gemacht hat, weil n Tab auch
quasi von der Formatierung her nicht immer quasi in in jedem
Editor dann auch die gleiche Länge hatte.
Und wenn du zum Beispiel NN Tab gemacht hast und sag ich jetzt
mal den Tab gelöscht hast, konnte es halt sein, dass zum
Beispiel die irgendjemand hat zum Beispiel Leerzeichen
verwendet. Irgendjemand hat wirklich Tabs
verwendet und mittlerweile glaube ich.
Ist ein. Tabak ersetzt mit Leerzeichen.
Genau, genau, ja. Aber das ist n interessanter
Punkt, weil der ist zum Beispiel, das ist mir auch
früher mal aufgekommen, und das kam, ich weiß es gar nicht mehr
genau, was kam, glaub ich auch dann zu Konflikten im Code unter
Umständen. Waren auf jeden Fall komische
Verhalten, also war n komisches. Verhalten und deswegen wird
jetzt eigentlich in der Regel, denn wenn du Tab drückst,
kriegst du halt deine Einrückung, die definiert es,
wird aber halt quasi mit Leerzeichen umgesetzt, sag ich
mal. Genau.
Und interessanterweise gibt es ja aber auch sprachen, die das
einfach voraussetzen, dass man das tut, wie beispielsweise
Python aus unserem Grundlagenkurs.
Java hingegen könntest du zum Beispiel sagen, OK, ich rück
nichts ein und es würde trotzdem kompilieren.
Und bei Python ist es aber so, dass dieses Intent, also diese
Einrückung erwartet wird und der Interpreter dann halt einfach n
Fehler wirft und sagt ja nee, hier da wird ne ne Einrückung
erwartet zum Beispiel. Nach deiner If Bedingung, also
der Code Anteil von von dem IF oder auch in der Funktion und
das find ich halt ganz spannend, weil das erzwingt diese
Formatierung dann auch. Ja, obwohl ich das, obwohl ich
immer noch n bisschen komisch finde, dass Python sagt.
Das Zeilenende wird durch einen Zeilenumbruch sozusagen
markiert, weil zum Beispiel bei Java ist es ja ein Semikolon.
Und ja, also ich fand das am Anfang genau.
Am Anfang fand ich es interessant, dieses Konzept so,
aber es gibt ja bei einigen Programmiersprachen aber ganz am
Anfang bei Python hat mich das auf jeden Fall schon so ein
bisschen so verwundert. Ja, es verhindert ja dann zum
Beispiel, was ich vorhin meinte, dass du einfach alle Anweisungen
in eine Zeile schreibst, was du mit Java theoretisch machen
könnte. Ich weiß nicht, wer das tut,
aber. Wäre theoretisch möglich.
Und Python? Würde es also.
Per Definition schon verhindern oder sagen, das geht nicht.
Ich denke mal auch hinsichtlich der der Codeformatierung.
Auf jeden Fall sind das so die ersten beiden Punkte, die viele
als trivial wahrscheinlich ansehen, gerade aber auch, weil
ID is das Auto formatieren sehr gut drauf haben mittlerweile.
Wenn man jetzt wirklich alles per Hand das noch machen müsste
mit dem Einrücken und allem würde mich mal interessieren wie
viele Leute da noch richtig wert drauf legen und das alles
richtig ordentlich machen das halt denn auch zum Beispiel jede
Funktion gleich eingerückt wird oder beziehungsweise jede
Einrückung immer 4 Leerzeichen sind und nicht 2 oder ob du in
einem Fall sagst Ach komm 2 ist in Ordnung.
Oder 4. Halt ne.
Aber das finde ich, ist jetzt auf jeden Fall ein nächster
spannender Punkt. Klar, also ich handhabe das auf
jeden Fall so, dass ich quasi Code schreibe.
Dann vielleicht. Sagen wir mal, man schreibt ein
If macht Klammer auf. Beispielsweise wenn wir jetzt
nicht bei Python sind, weil da wird das nicht mit Klammer
aufgeschrieben. Aber wenn ihr jetzt solche bei
keine Ahnung Java oder type Script oder frag mich nicht
verschiedenen anderen Sprachen, wo quasi die IF Bedingung
geklammert wird auf jeden Fall und du schreibst dann zum
Beispiel If Klammer auf und schreibst deine Bedingungen da
rein. Dann schreib ich das meistens
einfach hintereinander weg und mach dann hinterher n
autoformat, weil dann quasi die IDI meistens sagt OK es kommt n
if dann n Leerzeichen und dann Klammer auf so beispielsweise
ne, also es wird so n bisschen formatiert, halt n bisschen
eingerückt und sowas das ist halt so ne gängige Praxis.
Ich schreib Code eigentlich runter, hab aber natürlich dann
auch so weiß ich sowas wie Leerzeichen Leerzeilen also ein
Enter wenn du jetzt zum Beispiel keine Ahnung wie du meintest du
schreibst eine Funktion und dein Funktionskopf ist dann in einer
anderen Zeile als halt dein Funktionskörper.
Und so weiter. Das sind ja so Standard Dinge,
aber so jetzt irgendwie Leerzeichen oder so, da halte
ich jetzt nicht für an und sag jetzt if Leerzeichen und und
genau dann klammer auf so weißt du, das ist eigentlich relativ
wurst und ich schreibe das dann einfach so runter und dann mach
ich einmal autoformat was ich sehr interessant finde ist zum
Beispiel der Punkt, wenn wir jetzt gerade im Bereich vom von
vom Team, also in der Teamzusammenarbeit sprechen.
Man kann natürlich sagen, ja gut klar Lesbarkeit,
Verständlichkeit ist ja wichtig. Richtig ne.
Wenn wir jetzt aber noch mal wirklich auf die Effizienz der
Zusammenarbeit im Team gucken und.
Ist das ist eine Sache, die habe ich tatsächlich mal erlebt, weil
natürlich hast du Autoformate in IDES, aber dieses Autoformat in
IDIS kannst du ja selber einstellen, ne, und das ist uns
auf jeden Fall mal in einem alten Projekt von mir
unglaublich auf die Füße gefallen.
Weil du musst dir vorstellen, einer erstellt ein neues File,
schreibt da drin und committed das und pusht das so.
Irgendjemand zieht sich die neuen Änderungen vom von vom
Remote Repository und du hast sie dann und arbeitest dann
selber da an an dem an dem Pfeil irgendwann vielleicht eine Woche
später und baust neues Feature ein.
Musst irgendwie an dieses an diese Klasse ran dann zum
Beispiel ich dann schreibe ich da dran und mache genau das was
ich meinte ich schreibe dann irgendwie irgendwie eine IF
Bedingung irgendwas hin else noch mach autoformat und auf
einmal dass sich der ganze Code verrückt oh vielleicht merk ich
es auch nicht. In dem Fall war es eher so n hä
ist ja komisch na ja gut ist erst mal so so Anomaliemäßig
abgetan ist nicht so wild weil es war so ich hatte 4
Leerzeichen als Tab wie du es auch bevorzugst fand ich auch
gut, finde ich immer noch gut. Als Einrückung und irgendjemand
anders im Team hatte 2 Leerzeichen eingestellt in
seiner IDE, das heißt? Das File war in der Einrückung,
also jeder Einrückung hatte 2 Leerzeichen.
Ich habe Autoformat gemacht, alles wurde auf 4 Leerzeichen
eingerückt, das heißt im Endeffekt war die.
Zeile hatten Change gehabt. Jede.
Zeile hatten Change gehabt, genau so was erstmal so war
sowie ja gut, ok komisch. Naja, weiß ich nicht.
Es sind ja 4 Leerzeichen so eigentlich gesetzt im Team.
Also machen wir das so packe ich mal so mit rein, so wie gesagt
getan irgendwann später. Wieder das gleiche Verhalten und
dann kommt man irgendwann auf diesen.
Also es war dann so so n so n wieso ne Dynamik wo quasi
bestimmte Files immer auf 2 zurückgesetzt wurden, also auf 2
einrückungslehrzeichen und dann wieder auf 4
einrückungslehrzeichen und das ging die ganze Zeit so hin und
her bis irgendwann jeder so hart davon genervt war und sich
dachte warum zur Hölle haben wir so viele Changes bei uns, dass
man dann irgendwann sagte Moment Halt Stopp, wir gehen jetzt mal
alle zusammen die Ideen durch was da drin konfiguriert ist und
das ist halt eine Sache ich. Lesbarkeit, Verständlichkeit,
Codeformatierung ist wichtig. Das ist auch gut, wenn man die
einstellt. Nummern sollte sie innerhalb
eines Teams auch gleich einstellen, weil ansonsten kommt
es. Ansonsten wird es echt krude.
Das ist halt auch gleich der nächste wichtige Punkt.
Also klar, Formatierung ist einerseits Lesbarkeitsaspekt,
der sehr wichtig ist. Sorgt aber auch dafür, dass zum
Beispiel der Code einheitlich aussieht.
Und das ist halt genau das, was du gerade meintest, dass du
entweder zum Beispiel 4. Leerzeichen, einrückst oder 2,
also pro valide Einrückung sag ich mal.
Also ein Tab sinnbildlich und es ist so gesehen egal ob 2 oder 4.
Das ist eher so ne Präferenz des Entwicklers was er optisch
schöner findet. Ich finde das also bei 2 finde
ich fühle ich mich so ein bisschen beim Code lesen unwohl,
wenn man das so sagen kann, also ich.
Guck halt lieber. Auf Code, der mit 4 Leerzeichen
eingerückt wird, weiß nicht warum, aber es ist auch so eine
gewohnheitsding glaube ich. Das heißt, fühle ich also wenn
ich den Code so sehe, dann fühle ich mich wohler, ihn zu lesen
und zu verstehen. Aber ein Punkt, den du ja da
gerade mit genannt hast oder gezeigt hast, warum es wichtig
ist, ist ja auch wirklich, dass es einheitlich im Team ist.
Das heißt, es muss eine Teamvereinbarung geben an allen,
also mit allen Leuten, die an dieser codebasis mitentwickeln.
Einfach nur, wenn. Macht was er will, kommst du ja
genau zu diesem Problem, was du gerade beschrieben hast.
Ja. Richtig, und deswegen ist es gar
nicht so wichtig, ob 4 Zeichen einrücken oder 2.
Wichtig ist nur, dass es einheitlich ist, dass es n
gemeinsames Verständnis im Team gibt und Commitment darauf, dass
man halt quasi sagt Okay, wir haben sozusagen unseren eigenen
Standard, wie wir Code formatieren.
Ich finde. Man weiß ja auch jeder Bescheid
halt. Ich finde die einfachste
Herangehensweise für dieses, für diese Art und Weise ist, sagen
wir mal, das Team benutzt jeder die gleiche ide.
Das wäre auf jeden Fall schon mal eine erste Herangehensweise,
das nicht schlecht wäre, dass jeder die gleiche id verwendet
und ich bin halt einfach ein Fan davon eine IDE von der
Einstellung her so zu lassen wie sie ist, weil dann hast du also
außer einer IDE hat jetzt irgendwie keine Ahnung 20
Leerzeichen in der Einrückung, aber im Normalfall ist es ja
wirklich auch. Auf einen schönen, Leserlichen,
gut formatierten Code zurecht. Geschnitzt sag ich jetzt mal,
also voreingestellt. Das ist find ich.
Also ich hatte damit noch nie n Problem und für mich macht es
einfach Sinn zu sagen OK machen wir es so einfach wie möglich
und nehmen einfach die Einstellung von der IDI und
lassen die so wie sie ist und dann gibt es quasi.
Keine jeder stellt mal hier n bisschen was ein und hier n
bisschen was und so weiter also weniger Stellschrauben,
einfachere Einstellungen so. Ja, da muss man natürlich sagen,
dass es ja auch gewisse Coding Standards gibt, die jetzt nicht
nur von deinem Team definiert werden, sondern die so
allgemeingültig sind. Und da hast du ja zum Beispiel
das 4 Zeichen Einrückung Standard ist vielleicht auch 22
oder 4 sagen wir es mal so, aber es gibt jetzt wenige Leute die
jetzt 351 oder irgendwie sowas nehmen.
Richtig creepy. 1 wäre so richtig also auf gut deutsch
Scheiße zu lesen. Aber klar, du hast halt wie
gesagt einmal dieses Commitment im Team.
Andererseits sind diese Ideen schon so mit Best Practices
vorkonfiguriert in der Formatierung in dieser
Autoformatierung, dass man da eigentlich schon fast alles mit
abdeckt. Es gibt halt dann noch so ein
Paar, sagen wir mal Vorlieben oder Präferenzen so.
A oder b mäßig also, dass es so 2 Möglichkeiten gibt, wie zum
Beispiel 4 Leerzeichen oder 2. Was wir jetzt ja ausgiebig
versprochen haben. Ne anderes Beispiel wäre noch
was, auch wenn man sehr witziges Diskussionsthema ist, weil da
hab ich auch ne klare Ansicht. Weil wir jetzt zum Beispiel Java
hatten und die die IF Bedingung. Und die Einrückung haben wir
drüber gesprochen. So in Java sind aber so Scopes,
ja mit geschweiften Klammern definiert, das heißt?
Geschweifte Klammer auf, dann kommt der die Codeanweisung
rein, die deine wenn deine If Bedingung erfüllt ist und
geschweifte Klammer zu auch mal ganz kurz für Leute die jetzt
Java nicht entwickeln weil in Python gibt es das Halt nicht.
Und dann ist halt die Frage, auf welche Zeile kommt die öffnende,
die öffnende Klammer, also der geschweifte Klammer auf da gibt.
Es genau eine Antwort zu. Ja.
Für mich auch, aber in der in der Realität gibt es 2 Ansätze.
Ich habe beide auch schon verwendet.
OK, dann sag mal bitte was deine deine Präferenz ist.
Na, die geschweifte Klammer auf in der gleichen Zeile wie die
IF. OKOK das finde ich gut.
Wir können weiter zusammen Cohen, weil das sehe ich
genauso, für mich ist das auch einfach so, die Practice, die
ich mir da irgendwie über die Jahre angeeignet hab, obwohl ich
in Projekten gearbeitet hab, wo es nicht so war.
Und da ist die öffnende Klammer auf ne neue Zeile gekommen.
Das heißt, du hattest deine If Anweisung, also die If Bedingung
neue Zeile Klammer auf neue Zeile, dann warst du im Scope
von Deiner If Bedingung hast den Code geschrieben, noch mal ne
neue Zeile Klammer zu neue Zeile, weiter geht es.
Das habe ich heute das Konto machen im Studium.
Das ist, das ist auch ein absolut valider Weg, und das
machen auch einige. Zum Beispiel habe ich das
Gefühl, dass das so in der C. Welt verbreitet ist.
Haben wir nicht gelernt, dass in C das so gemacht wird?
Ja, vielleicht ist es in diesem ganzen C.
Universum könnte sein bei so CC Plus Plus habe ich das Halt
gesehen in den Projekten und C. Sharp ja stimmt, das hatten wir
glaube ich in der Community mal das Thema, dass das da
eigentlich auch so als Best practice angesehen wird, was ich
aber eiskalt ignorieren würde, weil das.
Das unterstütze ich nicht. Schreibt uns doch mal was eure
Vorlieben sind in Sachen wo. Kommt die Klammer her, kannst du
es. Bitte, schreibt uns.
Wir müssen gucken, was die Wahrheit ist.
Dann wird das durchgezählt und dann wird gevotet und dann wird
das so gemacht. Und dann will ich nichts mehr
hören. Es sei denn natürlich, es kommt
in ne neue Zeile, dann Veto. Auf jeden Fall ist das auch
wieder n klassisches Beispiel für.
Es gibt nicht richtig oder falsch.
Ja, also ja. Aber es gibt halt diese 2
Möglichkeiten und dann Herr Veto und da ist halt einfach wichtig,
dass man sich da im Team drauf einigt, weil wenn jetzt der eine
die Klammer in ne neue Zeile packt und der andere hinter die
Hüftbedingungen, dann ist das halt einfach wieder nicht
konsistent und das schadet dem gesamten Projekt und der
Software. Und ja, ich bin der Meinung,
dass Fordertierung so einen großen Impact haben kann, weil
allein wenn du nur jedes Mal darüber diskutierst im Team.
Ne lass so machen, ne lass so machen, verbrennst du ja auch
schon Zeit, das ist ja schon mal so der erste Punkt dabei, ne.
Und der zweite Punkt ist auch, zum Beispiel wenn du.
Einen Commit machst und guckst, wie viele Changes da sind, das
finde ich ist absolut nicht zu vernachlässigen und du guckst
dir wirklich, weil man sollte natürlich davon ausgehen, dass
wenn ein Code Review gemacht wird, dass man, dass es mit
Sorgfalt gemacht wird und dann guckst du dir jede Zeile, die
sich geändert hat an und wenn dann aber super viel.
Ich sag jetzt mal. Change Müll dabei ist.
Wo formatierungsbedingt? Genau, wo du halt einfach.
Du denkst, OK, ich guck mir das jetzt an und dann ist es aber
eigentlich. Quatsch, dass sich das wirklich
anzugucken. Und dann wirst du vielleicht
unaufmerksam und verlierst vielleicht ne Zeile aus den
Augen, die tatsächlich wichtig ist zum Reviewen dann ist halt
blöd und das ist. Finde ich auch n nicht zu
vernachlässigender Punkt, der durchaus ins Gewicht fallen
kann. Ja, absolut.
Bin ich ganz bei dir, dann ist halt natürlich die Frage, wie
die IDS eingestellt sind ne, weil wenn du jetzt zum Beispiel
deine Autoformatierung unterschiedlich dann wieder
einstellst wie in deinem Beispiel, dann wirst du ja
zwangsläufig, weil ganz ehrlich ist bei mir so automatisiert,
dass ich Code schreibe und danach den Shortcut für die
Autoformatierung Reinhaue, also so wirklich richtig
munterbewusstsein, das heißt ich würde ständig diese Changes
erzeugen, richtig, und das ist natürlich super nervig.
Dann habe ich ganz bei dir. Einen Punkt hätte ich noch.
Es hat dann doch wieder eine längere Folge gewonnen, auch
wenn es nur in Anführungszeichen um Formatierung geht.
Ich bin gespannt, es ist natürlich nicht nur.
Dass man im Team sich auf eine Formatierung einigt, die ja
hoffentlich sinnvoll ist und nicht einfach sagt okay wir
machen jetzt eine richtig sinnlose Formatierung, aber wir
committen uns im Team da darauf und alle halten sich verdammt
noch mal da dran. Ich greife noch mal diesen Punkt
auf, den du meintest. Diese Voreinstellung, von der
IDI ja schon meistens sehr souverän ist und ausreichend.
Es gibt ja auch Sprachenbedingt gewisse Coding Guidelines, also
Standardisierung. Sprachenabhängig das heißt, du
weißt jetzt zum Beispiel, OK, unser Projekt wird in Python
entwickelt, da gibt es einfach n Coding Standard für wie Python
Code so Best Practice mäßig auszusehen hat und der kann sich
natürlich auch wiederum unterscheiden von zum Beispiel
Java Code. Oder noch besser, weil Python ja
wie gesagt keine Klammern und mit Einrückung ist, sag ich mal
notwendig. Sagen wir doch mal zum Beispiel,
dass es ne unterschiedliche Coding Guidelines gibt von Java
und zum Beispiel C Sharp. Ne mit den Klammer.
Einrückung und so weiter. Ne, genau was wir jetzt ja auch
hatten als Thema und ich finde das ist halt auch immer n
wichtiger Punkt, wenn diese Sprache oder durch die
Entwickler durch die Community Guidelines existieren, dann
sollte man sich auch daran halten und nicht sowas wie.
Beispielsweise was das Cap ist, glaube ich.
Pascal Case wichtig. Bei den Namen komme ich immer
durcheinander, das heißt ich glaube Funktionsnamen fangen
immer mit einem großen Buchstaben an, das ist der
Unterschied zum Camel Case, was bei Java glaube ich dann die
Guideline ist, dass du da sagst okay ein Funktionsname fängt
immer mit Kleinbuchstaben an und dann wortgetrennt immer wieder
der erste Buchstabe groß, da sind sie dann gleich, aber wie
gesagt C auch der erste Buchstabe Groß Java der erste
Buchstabe Klein. Da gibt es, glaube ich bei C
auch noch so Ausnahmen beziehungsweise eine
Unterscheidung, ob es eine Klassen Name ist.
Funktionsname Variablenname will ich jetzt nicht weiter drauf
eingehen, weil wir auch einfach keine Sicherheit Entwickler
sind. Ist das irgendwas falsches
sagen? Aber da siehst du es ja schon
und es macht ja eigentlich wenig Sinn, wenn ich dann C Sharp
Projekt habe und aus der Java Welt komme und sage NÖ Camel
Case für immer, ich werde jetzt alles so benennen weil ich mein
was hat das was bringt dir das jetzt kommt im Team.
Also ihr, man braucht mehr Entwickler.
Die Firma stellt noch einen Entwickler für genau dieses
Projekt ein. N absoluter.
Fachmann in Sachen C. Kommt in dieses.
Projekt und man hat gesagt, ja ist alles Camel Case und der
denkt sich so. Schönes t Shirt Projekt was ihr
habt so richtig schön gegen diese standardisierten
Guidelines. Warum zur Hölle ich mein?
Er kann natürlich sagen, OK, wir einigen uns auf Camel Case, mach
ich, aber es ist ja komplett gegen seine Erfahrungen dann in
dem Moment und deswegen finde ich.
Wenn eine Sprache gewisse Guidelines hat, haltet er also
hält man sich auch da dran oder? Also oder wie siehst.
Du das ja, na definitiv. Also im Endeffekt ist es ja so,
dass man sich natürlich auch im Endeffekt genauso die Erwartung
an sich selber setzen kann. Also angenommen du schreibst.
Code jemand kommt rein und sagt. Was ist was hast n du hier
gemacht? So nach dem Motto Ne und wenn es
jetzt nur um die Eigenheiten dieser Sprache geht, wie du das
gerade so schön beschrieben hast, dann ist es ja trotzdem
blöd, weil es ja nun wirklich an sich auch keine schwere Sache
ist, das zu machen so, obwohl ich sagen muss, dass auch wenn
man jetzt zum Beispiel mal in Python programmiert, finde ich
es tatsächlich geht es sehr gegen meinen natürlichen
Schreibstil, sozusagen in dem Fall, ich glaube, das heißt
snaycase Ich bin mir gerade auch nicht sicher.
Wörter mit unterstrich zu trennen, das ist ja so ne Python
Richtlinie ne, weil wir ja gerade auch von Camble Case zum
Beispiel gesprochen haben und. Es wirklich.
Es widerstrebt mir, weil immer diesen unterstrich zu zu
schreiben find ich find ich wirklich schwierig oder
anstrengend oder ungewohnt ne ungewohnt ist glaub ich das
beste. Passt am besten, aber es ist
halt schwierig, aber trotzdem denk ich mir so ja OK, es gibt
bestimmte Guidelines und wenn die in Python nun mal so sind,
dann möcht ich mich ja auch daran halten, wenn ich in Python
Code ne. Also es gibt ja auch keine
Ahnung. Ich gehe auch nicht zu dir nach
Hause und wenn du sagst, so, ja gut, ich möchte aber gerne
bitte, dass zu Hause keine Schuhe getragen werden und ich
latsch die ganze Zeit mit Schuhen in deiner Wohnung rum,
weiß ich nicht, dann ist das. Irgendwie.
Die ziehst immer schön aus, Freundchen.
Das mache ich nicht. Ich will meine Schuhe am alten,
aber das ist halt so. Weißt du dann.
Dann denke ich mir so, es gehört doch einfach zum guten Ton, dann
auch wirklich zu sagen, ja gut, pass auf, wir sind in dieser
Welt, also nutzen wir halt auch die das Reglement sag ich jetzt
mal von dieser Welt. Arbeiten halt einfach damit und
das wirkt ja auch einfach professioneller.
Also wenn man jetzt zum Beispiel sagt, ja, ich möchte gerne ne,
also ich Fabian möchte gerne ein professioneller
Softwareentwickler sein oder vielleicht noch werden, wer weiß
das schon. Ist auf gutem Weg.
Danke. Danke.
Dann dann, dann ist es ja auch einfach, dann gehört es dazu,
sich auch daran zu halten, finde ich.
Und es ist halt wie gesagt auch nicht so schwer.
Ne und deswegen? Ja, aus maximal die Hürde, so
diese innere. Dieser innere Widerstand zu
sagen, Hey, ich find das nicht cool.
Das ist ja eigentlich so die genau, obwohl ich halt zum
Beispiel auch sagen muss, dass wenn ich irgendwas Code in
Python beispielsweise und ich denk mir so, ja, ich find
eigentlich camel case macht, mir find ich einfach besser lesbar,
sieht schöner aus, trotzdem wenn ich das irgendwas in mir in mein
innerer Monk sagt, du bist gerade in Python und es gefällt
dir nicht, aber du nutzt die Unterstriche ja, so ist es auch.
Ist bei mir genauso und dann ärgert man sich so, wenn man es
vergessen hat. Jetzt muss ich wieder alles
umbenennen hier refectern, weil ich mich da nicht dran gehalten
habe, das nervt aber. Im Endeffekt möchte man es ja
auch so machen und da sind wir auch wieder bei diesen ganzen
Punkten, die wir jetzt hatten. Es ist wahrscheinlich auch im
Team so kommuniziert, es ist der Standard der Sprache, also hält
man sich auch daran, weil das Ganze fördert dann am Ende auch
oder sorgt für eine super Formatierung und steigert auch
die Produktivität im gesamten Team.
Aber das ist einfach Fakt in meinen Augen.
Genau, und sowas kann man auch alleine gut üben, weil klar, es
sind immer Sachen im Team und auch wenn man damit anfängt und
noch nicht im Team arbeitet, es sind Low hanging fruits.
Man sollte sich auch damit auseinandersetzen, nicht einfach
irgendwie machen, wie man es gerne möchte, sondern vielleicht
auch für sich selber mal evaluieren, was macht denn zum
Beispiel Sinn, weil es kommt irgendwann genau an diesem
Punkt, dass zum Beispiel das genau solche Teamentscheidungen
getroffen werden und man. Vielleicht.
Dann sagt ja gut, ich würde das aber wahrscheinlich so machen.
Und wenn dann jemand sagt, Na ja, warum würdest du so machen
und du sagst keine Ahnung, dann ist blöd ne.
Also man hat natürlich dann irgendwie schon, man sollte sich
da am Anfang vielleicht auch mal n bisschen ausprobieren um zu
sagen, OK was gefällt mir gut welche.
Sage ich jetzt mal. Guidelines gibt es für die und
die Sprache und dann kann man quasi sagen okay ich, ich
arbeite in diesen Guidelines, ich halte mich an die Guidelines
dieser Sprache und in den Grenzen sozusagen der
Variabilität, was man halt ebenso selber ausprobieren kann,
da guckt man halt was für einen besser am besten geeignet ist,
weil im Endeffekt, wenn man irgendwann, sage ich mal, in
einem Team in den Austausch kommt und genau darüber redet,
dann kann man ja vielleicht auch sagen, du Pass auf aus den und
den Gründen mache ich das so und so, und vielleicht denkt sich
jemand anders, da stimmt das voll, die gute Idee.
Habe ich noch gar nicht dran gedacht.
Machen wir. So, oder du lässt dich.
Überzeugen also. Es gibt unterschiedliche Sachen,
deswegen ist es halt auch, wenn man damit anfängt auch
interessant sich damit auseinander zu setzen.
Ja, absolut. Und da ist halt dann wirklich
der Punkt, dass man auf einen Nenner kommt und alle sich daran
halten und damit auch glücklich sind, quasi so kurz entwickeln.
Ich finde man kann ja auch jetzt zum zum Abschluss der Folge
würde ich noch ne kleine Analogie bringen dazu.
Und zwar sagen wir ja immer. Es geht darum, den Code gut
lesen zu können. So, jetzt denkt sich vielleicht
der eine oder andere ja, hm lesen ja OK, aber du musst ja
wirklich, wenn du den Code verstehen möchtest.
Wenn du jetzt über das guckst, was jemand anderes programmiert
hast, dann liest du ja wirklich über den Code und nehmen wir
doch mal die Analogie, wirklich ein Buch lesen und jetzt sitzt
man da, schlägt das Buch auf, man liest, man liest die ersten
Seiten, es läuft, es fließt, man hat einen richtig guten
Lesefluss, so und auf Seite 5 geht es auf einmal los.
Dass irgendwelche random Absätze drin sind, eine ganz andere
Formatierung des Textes. So auf einmal hast du
Unterkapitel, die gab es vorher nicht, irgendwelche Random
Überschriften da drin denkst du so okay das ist eine andere
Schriftart, die Schriftgröße hat sich geändert, was auch immer
der Text ist ein. Dreieck man liest von rechts
nach links und von links nach rechts.
Ja, also vielleicht doch nicht mal so wild, aber einfach nur
die Schriftart hat sich geändert.
Die Größe hat sich geändert, die Formatierung, du kannst es zwar
immer noch von links nach rechts, von oben nach unten,
also ich gehe jetzt von einem deutsch geschriebenen Buch aus.
Du kannst es eigentlich genauso weiterlesen wie vorher, aber
jetzt soll mir mal einer sagen, das wird seinen Lesefluss nicht
beeinflussen. Das wird mein Lesefluss.
Nicht beeinflussen, OK. Taubt die Welt da gilt oder wie
war das früher immer? Nein, das werden wir prüfen.
Ich verstehe was du, was du, was du damit sagen willst.
Und das ist ne sehr sehr schöne Analogie.
Danke dafür. Das ist ja also, das kann man
sich auf jeden Fall mal durch den Kopf gehen lassen, finde ich
gut. Danke dafür für dieses Beispiel,
das. Find ich sehr sehr gut.
Da muss man natürlich sagen, Schriftart und Schriftgröße
spielt beim Code genauso. Ne Rolle, das stimmt.
Sollte auch einheitlich sein. Genau, ja, auf jeden Fall würde
ich sagen, haben wir das ganze Thema doch mal entspannt
auseinandergenommen und wieder zusammengesetzt.
Und ja, damit würde ich sagen, Tino, Dankeschön fürs Gespräch
für diese, den interessanten Austausch über ein zwar sehr
triviales oder langweiliges Thema eventuell, aber ich fand
es auf dem. Ersten Schein.
Auf den ersten Schein genau, man kann mehr darüber
philosophieren, als man vielleicht am Anfang denkt.
Deswegen danke für den Austausch und.
Ja, bitte, bitte hat Spaß gemacht.
Auf jeden Fall. Und in diesem Sinne würde ich
sagen, schließen wir die Folge ab, liebe Zuhörerin oder lieber
Zuhörer? Wie wir es schon mal gesagt
haben, schreibt uns doch auch mal was so.
Eure Coding Guidelines sind, was ihr vielleicht für interessante
Merkwürdigkeiten mittlerweile mitgekriegt habt, gelesen habt n
Code, was sehr sehr merkwürdig vielleicht war.
Gute Practices, die ihr rausgefunden habt, schreibt sie
uns über die Podcast Mail, gerne auch bei Instagram.
Wie ihr lustig seid die Links zu allen unseren Plattformen ist in
den Shownotes. Und ich würde einfach nochmal
gerne. An euch appellieren, wenn euch
diese Folge gefallen hat, dann empfiehlt sie doch einfach mal 2
euren Freunden, Arbeitskollegen, Kolleginnen.
Gibt einfach mal weiter und ansonsten würde ich sagen, hören
wir uns alle in der nächsten Folge wieder und in diesem Sinne
noch einen schönen Tag eure Coding Buddies.
Gemeinsam. Was?