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? 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?