Und jetzt kommst du als Teammitglied und guckst dir das an, denkst dir, was ist x was zur Hölle ist x oder ich komm 4 Wochen später und denk mir was ist XX ist 4 so weißt du. Bowling, Bodys deinem Podcast rund um Softwareentwicklung und aktueller Technews. Herzlich Willkommen. Ja, herzlich Willkommen zur neuen Folge des Covid Podcasts. Und nicht nur die neue Folge, es ist auch die 1.
Folge und Zwar hatten wir einen Jahreswechsel. 2024 und an meiner Seite natürlich wieder der fantastische Fabi. Moin, Moin Fabi. Hey Tino, ein frohes neues Jahr wünsche ich dir. Das wünsche ich dir auch. Mein schöner. Wie geht es dir alles gut? Ja, alles super gut. Reingestartet würde ich jetzt mal so behaupten, relativ entspannt. Wie war es bei dir? Ja, auch tatsächlich ziemlich entspannt. Also jetzt keine wilde Party, eher so im Kreis der Freunde und Familie.
Aber hat mir sehr gut gefallen. Also ich bin muss auch sagen, ich bin jetzt auch kein Mega. Fan von Silvesterpartys also, dass ich jetzt das ganze Jahr darauf hin Fieber. Aber es war schön, es hat Spaß gemacht, bin gut reingerutscht. Ja, wie sah es bei dir aus? Ja, ähnlich. Also Freunde, entspannte Runde war es, wir haben Raclette gemacht und dann klingt es geil und dann halt um um 9 schlafen gegangen, also. Am 1.1. Um 9. Ja, aber ich ich find es auch
immer. Also ich find es cooler, also so ich weiß nicht, also so viele gibt es, gibt ja viele die so richtig heftig so Party machen zu silvester, ich hab das auch ne Zeit lang. Also ich, was heißt gerne, ich fand es irgendwie, ich finde es für mich hat sich herauskristallisiert, dass ich es cooler finde, wenn man einfach so mit Leuten zusammen feiert, die man halt weiß ich, die man halt kennt, die man gut kennt, weißt du wo man halt. Auch irgendwie so ein. Weiß ich nicht.
Sich gehen lassen. Nein, du weißt was. Ich meine ja. Also ich find es halt auch irgendwie überbewertet, da irgendwie so n mega Partyabend draus zu machen. Also ich kennte oder ich. Bekannte Leute, die halt auch extrem darauf aus waren. Das muss die Nacht des Jahres werden so. Ja, für beide, für das Alte und fürs neue Jahr. Es ist einfach, steht alles in. China ist ja auch überall gar kein Druck, kein Druck. Kein Druck und dann wird es am
Ende immer Scheiße damit. Dann wird es halt immer irgendwie, dann ist die Erwartung einfach zu groß. Findet man selbst, wenn man sich keine Erwartung macht, find ich die Erwartung trotzdem immer. Irgendwie weiß ich nicht, also weißt du also irgendwie selbst wenn man sich so sagt, so, es ist ja ganz entspannt und dann denkt man sich trotzdem, ja, aber heute, so wie Silvester und ich sag mal ganz ruhig, es ist ja nur so alles, es ist doch nur Silvester.
Nee, also da muss ich sagen, dieses Jahr hatte ich nicht wirklich viel Erwartung oder hatte jetzt nicht vor, dass es sonst wie krass wird und es war halt deswegen einfach ziemlich cool. Es hat mir sehr gut gefallen, muss ich sagen. Das ist schön. So ganz entspannt halt ne. Böllerst du. Na, auf keinen Fall. Also ich meine, wir haben glaube ich lange nicht mehr Silvester zusammen gefeiert. Ne. Also wir haben.
Echt schon zusammen gefeiert? So ist es nicht und ich Feier auch sehr gerne mit dir Silvester, aber es hat sich nicht ergeben, ja. Weil du immer so hart Party machen willst und ich halt nicht. Du hörst mir einfach nicht zu. Nein, also das ist ja ein guter Punkt, müssen wir auch gerne mal wieder machen. Und zu deiner Frage mit den Böllern, das finde ich halt richtig furchtbar und sinnlos. Ich hoffe jetzt schalten dich die Leute aus. Und alle.
Machen aus, alle machen aus oder alle zünden erstmal irgendwie einen Balladen. Aus Prinzip. Also ich. Finde es also ich finde das finde das super furchtbar ehrlich mag ich gar nicht. Also ich finde es krass, weil ich Böller auch nicht mehr oder lasse raketensteigen oder so. Ich habe das aber früher übelst viel gemacht und also keine Ahnung, mein sechzehnjähriges
ich hat. Irgendwann mal von keine Ahnung, ich sag mal den irgendwie Freunden von meinen Eltern, die haben irgendwie gesagt sowas wie ja wir machen das so ganz entspannt, wir laufen machen so nen kleinen Spaziergang über 00:00 Uhr und dann knallen alle und wir gucken uns das an aber wir böllern selber nicht und ich dachte mir mit 16. Was geht eigentlich ab? Also das geht das überhaupt?
Ist das physikalisch möglich, keine Raketen Loszustarten zu Silvester, das fand ich voll krass, aber heute hat sich das bei mir halt so ein bisschen gedreht, weil ich das halt einfach irgendwie auch nicht mehr brauche.
Ja, also früher hab ich das auch gemacht und fand das natürlich auch irgendwo cool oder so. Keine Ahnung was ich mir dabei gedacht hab, aber mittlerweile denk ich mir so ist es halt irgendwie halt echt auch sinnlos und vor allem denk ich da mittlerweile auch anders drüber, gerade wenn man so Haustiere hat, was für n Stress das für so ein Tier auslöst und das merkst du ja extrem und da denk ich mir halt auch so, ist halt echt unnötig. Ja gut, aber das haben ja auch
nicht alle Haustiere, ne? Nein, aber ich verstehe, ich verstehe das, also ich finde es halt irgendwie ganz schön sich das anzugucken, aber ich kann es auch verstehen, dass das natürlich auch für für Tiere kann, also es ist sehr sehr stressig auf jeden Fall. Aber im Endeffekt war es, finde ich, um das ganze jetzt nicht daunergehen zu lassen. Ich hatte ein ganz gutes Silvester, es war ganz entspannt und ich sag mal so viel, ich hatte keinen Kater am nächsten
Tag und das war ganz gut. Das ging mir auch so, auch schön, gerade in unserem Alter katert man ja doch schon mal ein bisschen mehr. Ja genau gehe ich hier ganz mit. War bei mir ähnlich. Und natürlich dachte ich mir 00:00 Uhr so ja schön neues Jahr, das heißt, wir können bald wieder ne Podcast Folge aufnehmen und deswegen lass uns mal zum heutigen Thema kommen. Ja, was haben wir denn?
Das heutige Thema ist Silvester. Nein, und zwar hatten wir ja im letzten Jahr ne neue Reihe angefangen, und zwar die Cleancode Reihe und wollten ja einfach mal, weil es n sehr umfangreiches Thema ist, das n bisschen splitten auf mehrere Folgen. Und deswegen würde ich sagen, lass uns doch heute einfach mal die 2. Folge zu dieser Reihe. Quasi machen, aufnehmen, besprechen, wie auch immer und da.
Vorschlagen starten wir mal ganz entspannt mit der Namensgebung von beispielsweise Variablen und Funktionen. Das ist eigentlich immer n ganz cooles Einstiegsthema und klingt vielleicht jetzt für dich, liebe Zuhörerin, liebe Zuhörer, trivial aber ist es definitiv nicht und ist es auch nicht meiner Meinung nach selbst für erfahrene Entwickler nicht, da waren jetzt ganz viele nichts in diesen Sätzen, aber ich wollte
es einfach mal unterschreiben. Und deswegen fabi, was meinst du, hätte ich Bock auf jeden Fall mal mit dir drüber zu quatschen. Ja, auf jeden Fall. Also das ist ein wichtiger Punkt. Ich glaube, wir können ja erstmal damit anfangen, dass wir
gucken. Warum es überhaupt sinnvoll ist oder wichtig ist, bei der Programmierung, bei der Softwareentwicklung auch wirklich, sag ich jetzt mal, sich Gedanken darüber zu machen, wie Variablennamen, wie man diese Variablennamen oder funktionsnamen oder eigentlich jede Art von Benahmung im Code vergibt, belegt. Ja, das ist, das ist auf jeden Fall ein cooler Einstieg, weil
wenn man so drüber nachdenkt. Also wir haben ja in der Eröffnungsfolge ja eigentlich so mal eingeleitet, was Cleancode bedeutet, und da sind wir ja so auf Punkte eingegangen wie. Wartbarkeit, Skalierbarkeit, Lesbarkeit vor allem. Ja, und das sind ja alles Punkte, weshalb es klingt, quasi gibt oder diese Definition und so Best Practices und da zählt ja die Benahmung auch mit rein. Und genau aus diesen Gründen, weil gute variablen Namen, gute Funktionen.
Uns nahm und was gut ist, können wir ja gleich mal bisschen definieren, was so als gut gilt, sag ich mal. Sorgen ja aber dafür, dass du zum Beispiel den Code schneller und besser lesen kannst und besser verstehst. Also die Verständlichkeit wird ja auch besser.
Dadurch wird er natürlich wartbarer, weil ich einfach auch nach Wochen noch schnell weiß, was da passiert und das verstehe und kann es halt einfach besser warten und skaliere skalierbarer wird es auch, weil ich halt schneller beispielsweise wieder Schnittstellen finde, wo ich denn jetzt meine Funktion erweitern kann und da das alles gut lesbar wartbar ist, weiß ich halt, ach ja, genau das passiert hier, das passiert da und an der Stelle kann ich jetzt meine neue Funktionalität einbauen.
Also allein die Benahmung hilft. Dabei ja schon, das stimmt. Nahmung, also benahmung klingt halt immer sehr trivial. Aber. Ist es denn auch so trivial? Nee, absolut nicht. Also meinen Augen gar nicht und ich tue mich da auch heute immer noch schwer mit, beziehungsweise was heißt schwer. Man kann natürlich einfach irgendwelche Namen nehmen, aber wenn man halt auch, also ich sage, ich sag mal so mit zunehmender Erfahrung.
Arogen wird einem bewusst, wie wichtig denn diese Benahmung ist und deswegen versucht man im Vorfeld schon mehr Zeit da reinzustecken, um einfach später nicht diese Probleme, die man ja dann schon mal hatte, oder diese Erfahrungswerte, die man gesammelt hat, später nicht zu bekommen, sondern Monate später auf den Code guckt und sich denkt, Ach ja, ok, funktion sowieso, die macht das alles klar okay verstehe ich was da passiert, das ist ja so. Das wünschenswerte Ziel, sage
ich mal und nicht variable x mit Y. Geteilt durch ZB. Dann weiß ja keiner mehr, was da los ist. Also. Wie soll ich sagen, also. Und wenn du die Software schreibst oder sagen wir mal diese eine Funktion, dann bist du voll drin im Thema und dann sagst du dir OK, ja gut, jetzt
muss ich das machen. OK das und das ich brauch mal schnell ne Variable ja was dir gut die hält irgendein integer irgend ne Größe beispielsweise erreicht der die nenne ich jetzt x weil brauche ich ja nur hier und ja okay dann verwende ich x und fertig und. Kommst du als Teammitglied und guckst dir das an, denkst dir was ist x was zur Hölle ist x oder ich komm 4 Wochen später und denk mir was ist XX ist 4 so weit. Und das ist genau das Problem.
Ich find das beschreibt es halt ganz gut, weswegen so ne Namensgebung extrem wichtig ist. Wie sind denn da so deine Erfahrungen? Ja, also ich meine. Man was, was ich gemerkt habe, ist dass egal. Wenn man also wir beide haben jetzt mittlerweile schon so sind jetzt. Relativ längere Zeit schon erprobte Softwareentwickler in Anführungsstrichen sag ich jetzt mal. Ich weiß nicht wie ich. Das ja schon formuliert, wie ich das.
Jetzt ausdrücken soll. Aber wir haben ja schon einiges programmiert, wir haben schon einiges an einigen Projekten gearbeitet. Und ich finde, das ist natürlich besser, wird also dadurch, dass man halt eben ein höheres, höheren Augenmerk, höheres Augenmerk. Ich weiß nicht, wie man das sagt, höheres Augenmerk.
Klingt super, sagen wir so das. Spotlight wenn man also, man legt ja immer mehr, sag ich mal, schon Energie da rein bei Überlegungen da rein, dass man sagt, Okay wie könnte eine Funktion. Benahmt werden wie kann eine variable benatet werden, aber nichtsdestotrotz. Kommt es immer noch mal wieder vor, dass man sich vielleicht irgendwie mal auf sein, auch auf seinen eigenen Code, dass man da drauf guckt und sich denkt? Ah, warte mal.
OK was was genau passiert da noch mal ne und ich merk das halt immer wenn ich noch mal ne Funktion hab wenn ich da noch mal ne längere Zeit drauf gucken muss oder ne je länger ich da drauf gucken muss desto blöder war eigentlich die Vorarbeit ob es jetzt quasi mein Code war oder der Code von einem Teamkollegen in dem Fall. Der aber auch andersrum.
Also das ist halt immer genau der Punkt, dass auch wenn man jetzt eine Menge Erfahrung vielleicht schon mitgebracht hat, es ist nie so, dass also jedenfalls nicht immer hundertprozentig der Zeit, dass ich mir denke, okay, ich hab sofort den perfekten Namen für was auch immer, also man muss schon darüber nachdenken, merke ich, und das ist wirklich unglaublich wichtig, auch darüber nachzudenken und es.
Natürlich nicht so, dass du jetzt bei jeder Funktion oder bei jedem bei jeder variable Ewigkeiten drüber nachdenken musst und sagen musst, boah ey, keine Ahnung, ich hab jetzt irgendwie weiß nicht muss 10 Minuten drüber nachdenken. Das ist nicht immer so ne. Aber. Es gibt halt einfach schon Momente, wo man schon relativ schnell merkt, OK, an der Stelle sollte ich vielleicht wirklich
mal darüber nachdenken. Allein wenn du schon, wenn du diese Funktion schreibst und sagst, die soll jetzt die Funktion soll jetzt, die soll jetzt was, die soll jetzt das machen, aber die sagt, Na was passiert da eigentlich so weißt du also wenn du da wirklich mal so ein bisschen. Beim Codenummer selbst auch am Anfang. Irgendwas hinschreibt willst du erstmal loskommen? Du schreibst erst mal irgendwas hin und weißt aber vielleicht noch nicht so richtig hundertprozentig okay was ist
denn der perfekte Name dafür? Dann ist es mindestens ein Anzeichen, sich mal zu sagen okay, dann muss ich gleich noch mal gucken. Und das ist halt genau der Punkt. Also ich weiß, dass es besser wird. Ich persönlich lege mehr Wert darauf, gute Benahmungen für bestimmte Sachen, Funktion, Variablen namens Tests, was auch immer zu geben.
Und deswegen wird es besser. Aber man merkt trotzdem immer nochmal im Nachhinein zumindest ich, dass man da auch noch Potential nach oben hat und dass es eben keine triviale Angelegenheit ist, um zu sagen, das ist jetzt auf jeden Fall das. Das ist ganz spannend, weil vielleicht ist das unseren Zuhörern auch nicht so klar oder
vielleicht nicht allen. Das ist ja nicht so, dass man sich hinsetzt, 5 Minuten schweigt und sich überlegt, so okay ich hab's, wir nennen es so und so, sondern es ist ja wirklich ein Prozess, wie du schon meintest, man schreibt was hin, okay ja okay ja, das ist gut, nein, das lasst es lieber so nennen, okay gut, ja okay das doch das finde ich ganz gut, jetzt fängst du an, die Funktion zu implementieren. Aber eigentlich so wirklich beschreibt das nicht, was da
drin passiert. Und dann baust du um, dann wird die Funktionalität vielleicht noch ein bisschen geändert und dann ist es ja auch wieder wichtig, diesen Funktionsnamen anzupassen, weil vielleicht gar nicht mehr das wirklich passiert da drin, so wie es mal ursprünglich benahmt wurde und deswegen finde ich es geil, dass du sagst, es ist ein Prozess, weil wenn ich quasi mal aufnehmen würde, wie das dieser Prozess bei mir aussieht, dann schreibe ich was hin, lösch es
wieder weg, ich schreibe es wieder hin, okay finde ich gut, lösch es weg, schreibt das erste wieder hin was ich hatte lösch es weg, weißt du? Das das ist also, so sieht es ja eigentlich in Realität aus, das ist ja nicht so, dass es so eine Theoriearbeit im Kopf ist. OK, schreib ich diktiere weißt du und der andere schreibt das hin, so läuft es ja nun auch
nicht und. Sich diese Zeit aber zudem finde ich unfassbar wichtig und das findet man auch in vielen Lehrbüchern zu dem Thema. Das ist halt wichtig, ist mit den entsprechenden Argumenten auch, wie wir gesagt haben, dass es dir einfach im Nachhinein hilft. Ihre Software zu programmieren oder zu entwickeln, so dass man sagen kann, dass dieser dieser erste riesenpunkt halt wirklich ist. Verwende aussagekräftige Namen für Funktionen, Tests, Variablen, was alles, was halt
benannt werden muss. Aussagekräftig ist auf jeden Fall gut. Was mir auch noch mal ganz kurz zu diesem Thema einfällt ist. Oder was? Ich auch noch mal als Tipp vielleicht mitgeben kann, wovor man sich nicht scheuen sollte, ist. Tipps sind immer gut ist. Dass man zum Beispiel, also ich kenne das selber, ich hatte das auch schon mal, dass ich dann. Eine Funktionsnamen hatte also ich, ich mir waren. Ich hatte so ein paar mir überlegt, keine Ahnung, 5 Stück.
Und die ich war mal mit allen noch nicht richtig zufrieden, weil das war auch ne wertvolle Funktion für die Software, ne und dann hab ich halt auch wirklich nen Teamkollegen gefragt in dem alten Projekt und hab gesagt du pass auf ich hab mir jetzt diese 5 Namen mir überlegt für diese Funktion.
Ich bin mir aber nicht sicher, welche ich nehmen soll beziehungsweise meine Bedenken sind halt noch die und die und die, weil ich halt eben auch nicht hundertprozentig zufrieden, weil ich dachte mir so OK die der Funktionsname kommt schon irgendwie hin, aber irgendwas stimmt noch nicht so und es hat mich echt gewurmt, weil es halt wie gesagt ein
wichtiger Teil war und deswegen. Auch durchaus ratsam mal zu sagen, OK, selbst wenn man jetzt also was ich oft genug auch erlebt hab, war sowas wie ja dies das das dann hast du so vielleicht diesen Prozess den du geschildert hast. Auch der ging dann so vielleicht 3 bis 5 Minuten.
Und dann war irgendwann so, ach komm, wir lassen, wir nehmen das jetzt erstmal so und das hab ich auch schon oft erlebt und das sollte man vielleicht nicht unbedingt machen, also das kann man vielleicht einmal machen, aber wenn du es einmal machst, machst du es noch mal und dann hinterher hast du irgendwann genau den Effekt, dass du selber oder jemand anders darauf guckt und sich denkt, was ist denn das, dann brauchst du Zeit dafür, um das wieder zu verstehen und.
Wegen sehr guter Punkt. Tipp würde ich sagen, auch wenn man sich nicht sicher ist, auch noch mal wen anders fragen und noch mal ein paar mehr Meinungen oder Ideen, zumindest Ideen reinholen, das kann. Helfen finde ich sehr gut.
Ein sehr wertvoller Tipp, was natürlich bei solchen Geschichten, also wenn man da hin und her überlegt, kann es ja auch darauf hinweisen, dass es vielleicht schon eine Art Designfehler ist, zum Beispiel bei Funktionen bzw Fehler finde ich jetzt ein bisschen übertrieben, aber das ist
vielleicht. Cleaner geht das Ganze zu entwickeln, aber da würde ich jetzt nicht zu sehr darauf eingehen, weil Funktionen wie Funktion am besten aussehen oder was so best practice es sind finde ich ist eine super spannende extra Folge, also ein einzelnes Thema, weil da könnten wir auch echt bestimmt ziemlich lange drüber reden.
Aber was ich da immer spannend finde, und das würde ich halt kurz nochmal als Tipp mitgeben, wenn es mir zum Beispiel schwer fällt, Funktionen zu benennen, kann es halt einfach sein, dass sie auch nicht klar definiert sind, was passiert. In dieser Funktion, oder es passiert zu viel und ich glaube, das kennst du auch, das kenne ich, das kennt jeder, dass man merkt, so da. Eigentlich 2 verschiedene Sachen und wenn du dann sowas hast wie? Create or open, ja.
So was wie or or end. Das sind alles so Wörter, wenn ich versuche oder gewillt bin das in so nen Namen einzubauen, dann ist schon dann ist schon da was im Argen, dass da was nicht richtig ist. Also das find ich noch so als Tipp. Das sind so Schlüsselwörter, die symbolisieren. Oh, das ist geht vielleicht doch sauberer zu coden, dass man denn zum Beispiel Funktionalitäten, Auftrennt oder Variablen auch auftritt, weil man vielleicht
versucht zu viel. Wissen oder Inhalt in eine Variable zu packen, das klingt vielleicht erstmal n bisschen komisch, aber an solchen Punkten kommt man halt. Ja, wir hatten in der in der Twitch Session ganz coolen Kommentar zu diesem Thema, weil das irgendwie glaub ich in dieser in der einen Session auch gekommen ist. Da hatten Zuschauer in in den Chat gepostet.
Ist die Variable zu lang, dann willst du zu viel oder irgendwie sowas ne und ich fand den den ja stimmt, ich fand den Spruch ganz cool, weil der ist wirklich sehr ausschlaggebend ne also wie gesagt, ich glaube es ist. Ich nenne es mal so ne, wenn du ne Variable hast, die viel zu lang ist, ist das blöd. Wenn du Variablen hast die viel zu kurz sind ist das blöd und ich glaube man muss diesen süßen Mittelweg dazwischen finden.
Weißt du, dass du sagst? Es gibt diesen Sweet Spot, der einem sagt, Okay genau das ist, ist gut ne, also nicht zu viel, nicht zu wenig und ich würde das Zusammenfassen unter selbsterklärend, aber auch kurz und aussagekräftig. Ne, also diese 2 Punkte, die sind wichtig und und und. Das sind glaube ich gute Merkmale um zu sagen diese. Benahmung ist ganz gut. Ne ja find auf jeden Fall super zusammengefasst. Da würd ich aber abschließend noch noch ein letztes Beispiel geben.
Weil du meintest zu kurz ist auch blöd, da gibt es hab ich auch viele Entwickler schon kennengelernt, die sagen ja nee wenn man gewöhnt man sich dran oder so Abkürzungen sind ne ganz feine Sache. Weil Abkürzungen sind ja oft dafür da, um Sachen zu kürzen, Variablennamen beispielsweise. Funktionsnamen, so Abkürzung, finde ich, bin ich so ein bisschen. Vorbelastet, weil ich mal in einem Projekt gearbeitet hab, wo sehr massiv mit Abkürzung gearbeitet wurde. In Funktions und Variablennamen.
Und klar kann man sagen ja, wenn man das Wissen darüber hat, dann versteht man ja was das ist. Aber selbst ich, der täglich quasi an der Software geschrieben hatte, wusste irgendwann nicht mehr was beinhaltet die Variable jetzt eigentlich ist. Das ist das wirklich oder ist das wirklich die Funktion, die ich eigentlich aufrufen? Möchte im Kopf also. Steht diese Abkürzung für das, was ich hier eigentlich gerade haben möchte? Und dann? Ist es quasi so ein?
Gefühl, so in einem Lexikon nachschlagen und dann, ja, warte mal, wofür stand das noch mal? Ich weiß es nicht. Ich frag einen Kollegen, aber gut, ich weiß, Oh wo stand das und dann weißt du, wenn du mit sowas beschäftigt bist, ist es ein absolut klares Zeichen dafür, dass das kein Cleaner Code ist. Ja, also was ich zum. Beispiel meinen Augen ja definitiv, weil die damals waren ja der absolute. Verfechter von ja, das ist also.
Es ist halt auch eher also. 2 Sachen, die mir dazu einfallen ist weil vielleicht kannst du ja in einem Team ne bestimmte Konvention klären, ne. Also es gibt ja auch bestimmte Konventionen. Irgendwelche cases? Ne sowas wie camel Case oder was gibt es noch kebab case was was was gibt es noch? Es gibt Tausende Snake Case, zum Beispiel Pascal. Auch Gecoded hatten genau Pascal Sag ich schon, Pascal haben wir nicht gecoded Python mein ich. Aber wir können ruhig mal Pascal wieder.
Aufhalten. Schön doof, Pascal. Nee, Pascal. Nee, aber was, was auf jeden Fall, also das sind ja Sachen, die kannst du ja festlegen im Team, dass du sagst, OK, wir haben jetzt bestimmte Konventionen, wenn man zum Beispiel ne ne Funktion fängt, dann und dann so und so an, wenn sie in einem bestimmten Kontext ist oder was auch immer ich einfach mal so ganz allgemein
gesprochen habe. Wie gesagt, davon ab, dass es für bestimmte Programmiersprachen halt bestimmte Cases gibt, so wie Camel Case oder was auch immer ne die sollte. Man natürlich im Team auch Konventionen haben. Genau. Aber wenn die Konvention natürlich dahingehen, dass du irgendwann auf den Code guckst und dir denkst, hä, was passiert
denn da noch mal? Jetzt muss ich also, wenn du dir überlegst, du guckst auf eine Funktion, die du vielleicht eine Woche, 2 Wochen, Monat nicht mehr angeguckt hast und brauchst dann erstmal wieder keine Ahnung, ne 10 Minuten eine halbe Stunde bis du verstehst was da passiert oder vielleicht sogar noch eine Deep Session um zu checken, passiert das jetzt da
wirklich so, ahja. Doch ich hätte jetzt, ich dachte eigentlich, ich hätte nicht gedacht, dass er das auch so wirklich macht, dass er, also ich dachte, dass er da schon eigentlich in der Vorschleife abspringt, bei der Bedingung, aber irgendwie scheint das doch nicht der Fall sein, also wenn doch was anderes, genau, wenn du so weit kommst, dass du halt wirklich schon an an an Punkt kommst, wo du wo du wo du die wagen musst um zu verstehen was da passiert.
Wenn da vielleicht auch kein. Test angehen, aber ich meine. Nur mal so wirklich um, um um einmal das Ganze wirklich drastisch mal darzustellen, dann wird es halt dann heftig. Was heißt drastisch genau an dem Punkt waren wir oder zumindestens ich in diesem Projekt und ich weiß, es ging auch anderen so. Das ist halt nicht cool, weil da war es halt wirklich so. Ja, ich schreibe an meinen Klassen, ich kenne meine Abkürzung, die so definiert sind, ja, sage ich mal, ich weiß, was, das ist.
Ja gut, aber wenn du dann irgendwie woanders mal reinguckst einen Code oder halt selbst vielleicht Monate später, weißt du sicherlich nicht mehr, was die Abkürzung waren, weil da war kein vernünftiges Wort mehr drin, was du quasi in Klartext nenn ich es mal lesen kannst und will ich jetzt auch nicht zu sehr abdriften, aber das ist auf jeden Fall noch ein Tipp meinerseits übertreibt es nicht mit.
Abkürzung es ist halt wichtig dann wenn du halt im Team arbeitest, ist es natürlich wichtig, dass man dann halt auch einfach. Gut miteinander arbeiten kann und nicht nur an seinem eigenen Code arbeiten kann. Aber wenn wir jetzt zum Beispiel mal sagen, Pass auf, Wir haben jetzt zum Beispiel, wir haben Variablen, wir arbeiten im Team, wir haben jetzt jeder schreibt lesbare Variante, du kannst den Code lesen, weil die Variante sind schön zu lesen.
Ist es verständlich? Es ist ne Gute, es gibt gute Namen für diese variablen, sie sind es gibt einheitlichkeiten Konvention, was auch immer, wir haben selbsterklärende Namen, also zum Beispiel nicht nur irgendwie sowas wie Time, sondern ist das wirklich Timing millisecons oder so, dass du wirklich direkt siehst okay es ist nicht nur irgendeine Zeit, du weißt sogar was da für eine Einheit drinsteckt und es ist nicht so, dass es irgendwie kryptisch da ist.
Und es ist kurz und es ist aussagekräftig die Variablen. Sind aber auch richtig fantastisch was du sagst. Das haben wir alles, das ist, wir sagen jetzt, das ist alles wichtig, so, und jetzt kommt jemand her und sagt. Eine Zuhörerin oder ein Zuhörer und sagt, Leute, Ich arbeite gerade ich, ich lerne gerade Softwareentwicklung und mache das alleine für mich. Ich arbeite weder im Team, ich muss erstmal zu Rande kommen, so. Mögliche Situation kann ja vorkommen.
Ja, so was wollen wir auch. Nur was mittlerweile einige Jahre. Quasi nur zurückblicken auf unsere Studienzeit. Da hätten wir das wahrscheinlich auch gesagt oder gedacht. Oder genau genau. Und deswegen frage ich das jetzt ganz provokant mal. Was würde man also, wie könnte man jetzt sagen, Hey? Tino Warum? Namens. Warum ist das wichtig? Auch. Für andere theoretisch haben wir das ja auch schon besprochen,
weil das gilt. Für Anfänger, ich habe es ja auch anfangs der Folge gesagt, das ist ja ein Thema, das beschäftigt Anfänger, Fortgeschrittene und auch Profis und ich weiß nicht, ob es irgendwann den Punkt gibt, wo
das trivial wird. Das Thema, wo dir denkst ist doch klar, wie das Netz so und so klar, irgendwann hat man Erfahrung und auch Konvention spielen da rein, dass du sagst, ja ich bin in das so oder in unserem Team wird so eine Funktionalität immer ähnlich genannt, also in irgendeinem Schema, dass du da halt schneller drauf kommst. So was wie Klassiker insert at Fat, was auch immer. Also dass du so Konventionen auch dafür hast, dass du schon weißt, was da grob passiert. Aber.
Was jetzt habe ich ein bisschen den Faden verloren. Entschuldigung, aber genau weil das, das wird halt nie trivial, weil du trotzdem irgendwann immer dich damit beschäftigen musst. Und deswegen tangiert das genauso auch schon n Anfänger, der sich damit auseinandersetzen
muss, weil. Du kannst dir natürlich sagen, ich bin alleine und das ist jetzt hier nur ne irgend ne übungsaufgabe im Studium oder in meiner Ausbildung, aber wenn ich das später wieder rauf gucke und das ist, was wir ja vorhin besprochen haben. Da weiß ich nicht mehr, was da passiert und ich hab das ganz witzig. Also so so so n kleines n bisschen off topic nicht aber
mal so n bisschen nostalgisch. Ich hatte mir mal das auch schon ne Weile wieder her so alten Code angeguckt aus dem Studium den ich programmiert hab, krass und. Grundsätzlich dachte ich mir so, ja, war ganz vernünftig, was ich da gemacht habe. Also ich hab eigentlich gedacht, dass es viel, viel chaotischer ist. Also erstmal props mein Vergangenes ich. Aber trotzdem waren da so Punkte drin, wo ich mir dachte okay was macht diese Funktion und hier okay warum habe ich das damit so
benannt? Die Variable und da merkst du es ja schon, wenn du irgendwann später selbst noch mal drauf guckst und das muss jetzt nicht 10 Jahre später sein, wie in meinem Fall, sondern einfach nur vielleicht 23 Wochen später, weil du nochmal wissen wolltest, was da passiert ist. Dann hilft dir das da halt auch schon ungemein und außerdem hilft es dir einen besseren Coding Style zu kriegen, also dass du halt einfach auch Best Practices lebst. Wenn du dann halt in dem Team kommst.
Weil irgendwann mussten zwangsweise auch mal in einem Team arbeiten. Ich glaube, das lässt sich in seltensten Fällen vermeiden und dann ist das einfach Gang und gebe, dass das so gelebt wird, oder oder wie siehst du das? Ja, also wie gesagt es. Ich finde das auch. Nur wenn ich jetzt, also wenn du das auch gerade meintest, so wenn. Rückversetzen hätten wir das auch nicht gemacht beziehungsweise wir haben es nicht gemacht, uns darüber Gedanken zu machen.
So und jetzt würde ich zum Beispiel sagen, OK, erstens alle dir zuhören und sich denken, ich fang gerade an, macht es besser, weil dann seid ihr schon mal. Ein Schritt voraus ihr könnt Übung, also Übung, darin sammeln, zu überlegen, wie könnte man denn etwas gut benahmen. Und meine Erfahrung nach von früher, ich hab n Code geschrieben für irgend ne übungsaufgabe im Studium. Anfang der Woche ging's los. Ich hab. Angefangen diesen kleinen Minialgorithmus zu entwickeln.
Hab da ne Pause gemacht von 2 Tagen.
Hab mich danach nach am dritten Tag sozusagen wieder dran gesetzt, hab mir angeguckt weil ich da geschrieben ich wusste nichts, ich hab mir ich hab da drauf geguckt und dachte mir so was hab ich denn keine Ahnung und dann ging es wieder los da musste ich erst mal gucken was habe ich da gemacht, wie funktioniert das weil ich einfach also da kommen natürlich andere Sachen mit rein die auch noch bei Cleancode wichtig sind die wir auch noch diskutieren wollen aber allein schon dieser
Punkt, der hat mich schon dieser Punkt hat mich schon aufgehalten und ich denke mir richtige Benahmung darüber nachzudenken, wie man etwas nennen könnte, das sind Low hanging fruits, weißt du die kannst du, das kannst du relativ easy üben, also du musst jetzt nicht gleich mit, keine Ahnung die Penancy Injection oder sonst was ankommen, irgendwas wo du dir vielleicht wirklich am Anfang denkst. Hä was soll das?
Keine Ahnung ich weiß es nicht ganz entspannt immer 1 nach dem anderen, aber sowas würde ich jetzt zum Beispiel sagen, da kannst du halt als Anfänger relativ gut einfach mal ein bisschen drüber nachdenken und es ist definitiv keine Raketewissenschaft die da dahinter steht. Ja, das ist halt so. N klassischer Fall von easy to Learn, Hard to Master oder wie das heißt.
Ja ne, aber es ist ja so. Du hast natürlich recht, man kann es sehr leicht üben, indem man sich einfach damit auseinandersetzt, ne und ich würde sagen, dass auch die Code Qualität enorm steigt, indem man dadurch also indem man anfängt sich darüber Gedanken zu machen zu machen, egal wie simpel der Algorithmus ist oder wie klein die Software, aber die allgemeine Code Qualität von dem Code den ich selbst entwickelt zu dem Zeitpunkt, der also diese Qualität steigt enorm an dadurch
und das. Andere Entwickler später danken also, dass sie das besser verstehen, was du machst und du selbst wirst es dir auch denken, danken, denken, danken. Weil guck mal, wenn du sagst nach 3 Tagen oder nach 2 Tagen bei so n bisschen Code mal Prokativ gesagt hast du schon nicht mehr verstanden was da eigentlich passiert ohne dich noch mal reinzudenken, dann ist das ja schon n super Beispiel dafür zu sagen, OK hättest du mal da 5 Minuten Zeit reingesteckt, mal auch wieder provokativ.
Gesagt, das Ding. Ist bei dir und ich hoffe, dass das halt auch, dass diese Message angekommen ist bei dir. Liebe zuhören liebe Zuhörer, falls du genau an diesem Punkt stehst, dich damit auseinanderzusetzen, dass es sich auf jeden Fall. Und auch zukünftig lohnt genau, sich damit zu beschäftigen. Und es ist ja auch nicht so, um das noch mal abschließend zu sagen, weil das ist mir auch noch mal wichtig. Es ist nicht, es ist nicht so, dass du ganz am Anfang dir immer gleich überlegen musst.
OK, wie benenn ich das jetzt, wie funktioniert das jetzt.
Wir hatten ja gesagt, das ist ein Prozess, das kann man auch hinterher machen, man kann auch erstmal die Funktion schreiben, sich hinterher noch mal hinsetzen und sagen, okay, es funktioniert jetzt so, wie ich es mir vorgestellt habe und jetzt gehe ich noch mal durch und überleg noch mal, finde ich irgendwo eine Variable, die temp Test x ABC was auch immer heißt oder eine Funktion die was auch immer heißt testfunktion Testfunktion, also dass man wirklich sich noch mal überlegt
okay, also auch im Nachhinein nicht, vielleicht nicht unbedingt im Vorfeld, aber vielleicht auch im Nachhinein, weil am Anfang ist es vielleicht noch nicht ganz klar, was man vielleicht wo man hin möchte oder wie es aussehen wird, aber dann im Nachhinein das nochmal zu refact an das ist glaube ich wichtig, dass man sich da vielleicht auch noch mal Gedanken macht, das ist einfach vielleicht auch hilfreich, wenn man denn nicht immer gleich von vornherein direkt.
Ne Stunde Zeit nehmen will für die nächste Variable. Ich hab jetzt übertrieben, ja, aber. Bin ich auf jeden Fall ganz bei dir.
Bevor wir die Folge beenden, hätte ich noch einen Punkt, was mir auf jeden Fall, glaube ich, geholfen hat, wenn man mal so drüber nachdenkt, da würde ich auch nochmal kurz gerne deine Meinung zu hören und zwar glaube ich oder aus heutiger Sicht würde ich auch den Tipp noch mitgeben, so abschließend, dass es hilfreich ist, sich auch einfach mal professionell geschriebene Software anzuschauen, sei es irgendwelche
Packages, libraries. Irgendwelche Repositories auf github, die halt sehr gut bewertet sind oder viel verwendet sind und mal schauen wie da so Variablen und Funktionen quasi benannt wurden und versuchen zu verstehen was da passiert und einfach mal so ein bisschen best practices. Zu leiten daraus, und genau diese Konvention, die wir auch genannt haben, dass man so zum Beispiel ne Einheitlichkeit schafft, indem man so Schlagwörter wiederverwendet, sei es sowas wie es heißt, length.
At insert weißt du also die Sonne, Sonne, Schlagwörter, dass du Funktionen damit schreibst, werden ja immer wieder kommen und dass man das auch einheitlich hält. Es gibt ja so Team at. Es gibt Team Insert und weißt du also. Das ist ja auch zum Beispiel von Library Sol Library wieder unterschiedlich, aber trotzdem weiß man ja was das also du, du hast ne Klasse und liest diese Funktion und weißt einfach was da passiert.
Also man kommt halt relativ schnell dann auf den Inhalt und da kann man sich glaub ich ziemlich coole Best Practices auch ableiten und dass es sich bestimmt lohnt auch als Anfänger da schon mal reinzuschauen, man muss ja nicht im Detail verstehen was da passiert, aber dass man einfach mal die Benahmung. Liest und sieht, wie gut der Code aussieht. Ja, und vielleicht auch einfach guckt, was da so für Benahmung gibt. Wenn man jetzt nicht gerade, also weil du ja auch meine
Meinung wissen wolltest. Ist ein wertvoller Tipp, würde
ich auch sagen, sollte man auch. Vor allem also würde ich auch sagen, als fortgeschrittener Programmierer oder Programmiererin auch sehr gerne machen, sogar noch wichtiger meiner Meinung nach, weil zumindest kann ich nur aus meinem eigenen Nähkästchen plaudern, wenn ich mir manchmal ein Paar, sagen wir mal, du kannst ja auch bei Java oder so, wenn du dann in eine Funktion reinsteppst aus einer Library, da war ich dann relativ am Anfang auch relativ schnell
überfordert, weil ich mir dachte, okay, was ist das denn, da ist jetzt ein. Sogenanntes Generic mit drin und ich wusste nicht was das ist am Anfang. Also es gibt Momente, wo man quasi natürlich lernen kann aus solchen Libraries oder auch Repositories, die öffentlich einsehbar sind gerade. Wie wenn wir jetzt über Benahmung sprechen, ist es vielleicht durchaus wertvoll. Es kann aber auch abschreckend sein für mich zumindest.
Damals wäre es, es war es manchmal n bisschen abschreckend, weil ich mir dachte, wow, ich hab keine Ahnung, was da passiert und ich bin ja wahrscheinlich sehr, sehr schlecht. Ja, also das ist. So, ja gut, also das soll natürlich nicht abschreckend wirken, ne, also man soll sich davon noch nicht abschrecken
lassen. Das wär natürlich negativ oder so genau die falsche Auswirkung, denn daraus sondern eher man muss ja wie gesagt nicht im Detail verstehen was da passiert, aber man kann also das kann sich halt visuell einbrennen, wie guter Code aussieht, wenn ich zum Beispiel dazu neige, 100 Zeilen eine Funktion lang zu machen und guck dann aber mal so rein, wie sag ich mal Profis das schreiben und sehe halt alle ziemlich kurz die Funktion warum, warum weißt du,
dass man halt so merkt, also Style kann kann man ja auch so verinnerlichen durchlesen. Weil ich finde das ganz spannend. Ich hab mal nen Artikel gelesen, der war sehr provokativ geschrieben, auch Richtung verbessert dich als Coder selbst sozusagen und da war der Punkt drin. Ja, wer von euch Codern liest
denn überhaupt Code? Und damit war wirklich gemeint, wirklich mal in andere Projekte rein zu gucken, die sehr erfolgreich sind und auch als allgemein sehr gut gelten, zu gucken wie da drin gecoacht wurde oder implementiert wurde. Und das ist n Punkt, den mach ich selbst auch sehr wenig, was eigentlich ja schade ist. Definitiv, vor allem gerade, wenn man sich überlegt, dass als Beginner man sich natürlich auch
schon Code viel angucken muss. Ob es jetzt, sei es jetzt in irgendwelchen Folien. Von Uni oder Ausbildung, was auch immer. Lehrbüchern ne, man guckt sich ja wahrscheinlich zwangsläufig Code an um zu sehen wie funktioniert, überhaupt, wie funktionieren die Basics. Aber sich auch mal hinzusetzen und zu sagen, vielleicht auch mal ehrlich zu sich zu sein, wie oft gucke ich mir Code von anderen Leuten an, von also hochwertigen Code auch der.
Sehr wahrscheinlich hochwertig ist sag ich jetzt mal. Das kann man sich mal Fragen, hinterfragen und das vielleicht auch. Genauso weitermachen oder besser machen und sich vielleicht auch als, na ja, wie sagt man Neujahresvorsatz vornehmen und sagen. Wir haben ein neues Jahr. Nehmt es euch als Neujahrsvorsatz genau, ich lese Code. Noch mal zu machen und in diesem Sinne Tino, würde ich sagen. Schließen wir mal die Folge ab, ja. Haben wir jetzt echt sehr ausführlich besprochen.
Hat mir auf jeden Fall Spaß gemacht. Danke für Deine Insights und für deine Gedanken zu diesem Thema. Ja, bitte, bitte. Und dann würde ich sagen. Falls dir die Folge. Gefallen hat, liebe Zuhörer, lieber Zuhörer, dann nehmt euch auch als neueres Vorsatz vielleicht diesen Podcast 2 Leuten weiterzuempfehlen, Arbeitskollegen, Studienkollegen, Kommilitonen,
sagt man dazu, glaube ich. Freunde und verwandte, Freunde, Verwandten. Alle, die es interessiert in Sachen Softwareentwicklung oder halt auch darüber hinaus, das würde uns sehr freuen und. Wie gesagt, gebt uns auch gerne Feedback zu dem Podcast über Instagram, die wir haben auch eine Podcast Mail in den Shownotes alles unten verlinkt und ich hoffe wir hören uns beim nächsten Mal wieder. Schaltet wieder ein in der nächsten Folge und bis dahin. Eure Coding Buddies gemeinsam besser.