Die Funktion heißt Würze mein Essen und du Schüttest da Salz rein und Kräuter und Paprikapulver und noch Knoblauch und alles so. Warte mal Paprikapulver rosenscharf oder Edelsüß. Holding Bodys dein Podcast wohnt im Softwareentwicklung und aktueller Technews?
Herzlich Willkommen. Ja, herzlich Willkommen und Halli Hallo zur neuen Folge des Coding Buddies Podcast und wieder mal mit dabei wie immer kurze Einführung meine Wenigkeit, der Tino und natürlich auch der fantastische Fabi Moin Fabi, herzlich Willkommen zur neuen Folge. Moin Tino, Wie geht es? Wie steht es? Ich spüre die Energie, spür es richtig, geht es dir gut?
Ja, also ich weiß nicht irgendwie, ich habe jetzt gerade beim Podcast wieder voll Energie, aber eigentlich bin ich ein bisschen müde, muss ich ganz ehrlich sagen heute, ich weiß gar nicht warum, aber. Ausgefahren, das heißt, wenn es heißt, wir nehmen jetzt n Podcast auf, dann bist du so gehyped und hast so Bock drauf, dass deine ganze Lebensenergie zurückkommt oder? Auf jeden Fall hab ich das so verstehen auf jeden Fall. Ja, ich lebe. Das ist in diesen Podcast. Ich lege für diesen.
Podcast weil die Bestimmung diesen Podcast aufzeichnen, weil ich lebe, weil wir diesen Podcast machen. Ach so, also so OK, den finde ich gut, das ist genau das Mindset, was wir hier brauchen, um bestmöglichen Content zu liefern. Deswegen sage ich mal, lass uns nicht so viel ins Off topic rutschen, dafür haben wir ja eigene Formate hier im Podcast. Deswegen würde ich sagen, habe ich noch ein Thema mit und das würde ich gerne mit dir heute
mal besprechen. Und zwar ist es mal wieder soweit für eine neue Folge zum cleancode Thema. Ja, ich sehe deine Begeisterung, du hast Bock, du hast Bock. Grüße gehen raus. Genau. Der Meister. Genau. Und zwar hatten wir ja schon, ich glaube, 2 Folgen hatten wir doch jetzt schon gemacht, oder? Zum Cleancode ja genau, also ist heute die 3. Folge. In der letzten hatten wir glaube ich über Benahmung gesprochen, von Funktion und Variablen so ganz allgemein.
Was es da so zu beachten gibt und was als Best Practice gilt, was nicht so gut ist, was so n bisschen unsere Meinung dazu sind und genau auf dieser Ebene würde ich gerne weitermachen mit dir. Nur dass wir ein anderes Thema.
Natürlich haben wir nicht noch mal das gleiche Leben und zwar würde ich sagen, lass uns doch was hier los, lass uns doch heute mal über Funktion allgemein reden, ja Funktion betonen, je nach Sprache wie man sie nennt, aber wir definieren noch mal kurz, was wir jetzt damit meinen, würde ich sagen und dann können wir ja mal so ein bisschen darüber reden, was unsere Meinung dazu ist, was ein ganz guter Stil ist oder was wir versuchen zu vermeiden und gehen natürlich auch so ein bisschen
auf diese allgemeine cleancode Bewegung wieder ein, was? Danach quasi Best Practice ist oder wollen wir das so machen? Finde ich gut. Okay dann würde ich sagen, gib uns doch mal ein Frame. Also, liebe Zuhörer, liebe Zuhörer, dass wir einfach mal alle jetzt hier zusammen, wie wir da sind, quasi wissen, was jetzt mit Funktion gemeint ist. Fabi, magst du da mal starten? Ja, sehr gerne. Also Funktion sind ja im Endeffekt, ich versuche das ein bisschen kurz zu halten, sind quasi abgekoppelt.
Code Stücke, die man immer wieder sozusagen ausführen kann und meistens oder im Normalfall sollten diese Funktionen halt auch quasi dafür da sein, dass eine bestimmte Aufgabe erfüllt wird, damit man halt eben seinen Code zum Beispiel auch wiederverwendbar machen kann oder modular halten kann.
Solche Sachen und mal ein kleines Beispiel zu geben, wenn man sich das jetzt vielleicht überhaupt nicht vorstellen könnte, kann man sich das vielleicht so ein bisschen vorstellen, angenommen, du möchtest jetzt zum Beispiel.
Du möchtest was kochen und jetzt hast du irgendwie so dein dein Rezept in der Küche und gehst in das Rezept durch und irgendwann an einer Stelle im Rezept kommt zum Beispiel okay du musst jetzt vielleicht irgendwie für eine Suppe was pürieren, so, das heißt du nimmst dir deinen Mixer und du packst in den Mixer, packst du halt entsprechende Utensilien rein, die dann gemixt werden sollen, also zum Beispiel, ich sag jetzt mal, du willst jetzt irgendwie eine Zwiebelsoße machen, dann machst
du da Zwiebeln rein, dann kommen da noch was weiß ich ein paar Nüsse und paar Pilze rein, ich weiß es nicht. Verrückt? OK, also merkt euch das Rezept, also das Rezept findet ihr auch auf chefkoch.de. Einfach mal Google. Nee, auf jeden Fall. So, und dann musst du halt, dann ist das fertig, dann erhitzt du die noch, packst noch n paar Kräuter rein, was auch immer so, du hast so n Ablaufplan. Mhm.
Und wenn du jetzt mal als Analogie keine Funktion benutzen würdest, dann würde es ja bedeuten, dass du sozusagen, wenn du eine, wenn du diese, dieses dieses Gericht kochen möchtest, dann brauchst du einen Mixer, den du nur, also die in diesem Mixer kannst du nur mit Pilzen, Zwiebeln und Nüssen, was ich auch immer ich gerade gesagt habe, befüllen.
Und wenn du ein anderes Rezept kochen möchtest, also zum Beispiel möchtest du etwas machen, wo du auch einen Mixer brauchst, zum Beispiel Smoothie, dann brauchst du noch einen zweiten Mixer, weil für der eine Mixer, den du hast, der ist ja wirklich nur dafür da, um Zwiebeln, Pilze und Nüsse. Zu sag ich mal zermixen wenn du das ganze jetzt aber auslagerst und sagst okay das mixen an sich ist eine Funktion und ich habe Parameter, die ich sozusagen in diese Funktion mixen reingeben
kann. Also die Zutaten in dem Fall.
Genau die Zutaten. Dann bin ich ja sehr, sehr variabel, das heißt, ich kann quasi sagen okay, ich habe ein Rezept und innerhalb dieses rezeptes rufe ich jetzt sozusagen die Funktion mixen auf mit bestimmten Paraden, also mit den entsprechenden Variablen und was ich zurück kriege als Return wert beispielsweise was mir diese Funktion zurückgibt ist dann das Endresultat des Mixes. Also ich nenne es jetzt mal die Soße, den Smoothie, was auch immer dieses Erzeugnis was da
entsteht ne so und so kann man sich das bisschen vielleicht vorstellen als. Analogie wie das im Code funktioniert ne, also du hast quasi eine Berechnung die du irgendwie anstellen möchtest und diese Berechnung ist in bestimmten, also hat bestimmte Parameter, die reingegeben werden müssen und damit wird dann diese Berechnung stattgefunden, also durchgeführt mit den Begrenzungen, dass du zum Beispiel natürlich auch bei diesem Mixer nur eine bestimmte
Möglichkeit von Input hast. Also du kannst nur, ich sag mal, bestimmte Lebensmittel reingeben. Du kannst ja jetzt nicht schrauben reinwerfen oder was auch immer, also ist es bei Funktionen ja zum Beispiel auch so, dass du dann als Parameter, wenn du zum Beispiel integer rein gibst, kannst du jetzt vielleicht nicht unbedingt Strings oder so verwenden, weil das ist ja vorgegeben.
Damit würde ich sagen, das wäre jetzt so meine Analogie zum Thema Funktion. Ja, OK, es sei doch n bisschen umfangreicher geworden, aber ich denke, es ist war ganz gut verständlich. Was man jetzt ergänzend sagen kann, das ist ja jetzt nicht nur mixen. Du könntest ja jetzt so n Set an Funktionen dir schreiben. Mixen. Braten. Schneiden, was auch immer und damit dann quasi verschiedene Programme implementieren. Was du jetzt als kochrezept
bezeichnet hast. Und dann kannst du halt verschiedene Gerichte kochen, im Endeffekt ne find ich gut. Genau so kann man das dann aufbauen, ja. Genau. Und dann kannst du es halt immer wieder verwenden, weil du ja in mehreren Rezepten zum Beispiel die Funktion braten brauchst oder mixen genau richtig.
Ja genau, ja, auf jeden Fall vielen Dank nochmal für die Einführung, weil wir haben ja auch einige Zuhörer, die noch uns zuhören, die ganz am Anfang der Softwareentwicklung stehen und ich denke, dass so eine Analogie da eigentlich immer ganz geil kommt, um das so mal zu verstehen, wenn man noch an den Anfängen ist. Was wir jetzt damit eigentlich
meinen. Und alle erfahrenen Zuhörer danke fürs Dranbleiben. Jetzt kommen wir zum teat Thema, aber auch jetzt haben wir einmal abgesteckt, worum es geht. Genau. Wenn es jetzt um Funktionen geht, noch mal n kleiner Reminder oder ne Zusammenfassung der letzten Folge haben wir gesagt, dass die Namensgebung sehr essentiell ist bei Funktion um einfach zu wissen, wie du ja
gerade meintest. Diese Funktion nimmt ja im besten Fall eine Aufgabe an. Dass quasi der Name der Funktion sehr gut beschreibt, was innerhalb dieser Funktion passiert, damit ich von außen, wenn wir jetzt noch mal die Analogie nehmen, das Kochrezept genau weiß.
Wenn ich diese Funktion verwende, was passiert genau, du willst ja nicht zum Beispiel ja, also zum Beispiel jetzt, wenn man noch mal das Kochrezept nehmen, wenn ich die Funktion braten aufrufe und sage okay was will, was ist die Eingabe Anzahl der der Stücken Fleisch oder was auch immer oder Gemüse.
So, dann will ich ja nicht, dass die Funktion aufrufe erwartet, dass irgendwas angebraten wird und dann aber da drin gekocht wird oder so. Also jetzt einfach nur ins Wasser geschmissen wird, gemixt und genau oder gemixt, worst Case gemixt. Und das ist halt genau da sieht man ja anhand so so eines einfachen Beispiels schon, dass irreführende Namen zu ziemlich großen Problemen führen können.
Und deswegen würde ich diesen Punkt aus Funktion, weil wir es in der letzten Cleancode Folge ja besprochen haben, rausnehmen. Nur noch mal so kurze Erinnerung, die Namensgebung ist halt sehr essentiell. Was ist für dich dann ein weiterer, sehr wichtiger Punkt? Also was würdest du sehr hoch priorisieren, was dir bei Funktionen wichtig ist?
Was mir wichtig ist, ist, was ich schon mal so n bisschen, also was ich auch schon mal n bisschen angeschrieben hab am Anfang. Also du willst ja mit einer Funktion eine bestimmte Funktionalität im Normalfall abkapseln, ne, also du möchtest sagen wie wir Grad gesagt haben mixen oder braten du möchtest jetzt aber nicht, also was zum Beispiel schlecht wäre wenn man jetzt eine Funktion schreiben würde die da heißen würde zum Beispiel kochen und braten.
Oder ZB. Rühren oder mixen oder was auch immer. Weißt du, dass du sozusagen genau in einer Funktion eigentlich sagst, mache entweder dies oder das beziehungsweise mache dies und das mal als Beispiel, sondern dass man wirklich darauf achtet, dass man sagt Okay, was haben wir denn für kleinste Einheiten, logische Einheiten, die man zum Beispiel verwenden oder beziehungsweise durchführen kann und beziehungsweise rechnen kann und an der Stelle ist es ja zumindest so, dass man jetzt
sagen kann okay, du hast eine Funktion, die dir sagt Okay berate das. Koche das, Mixe das, rühre das und diese ganze Logik, die Drumherum stattfindet. Das ist ja quasi das, was sozusagen dann von außen passiert. Also bei den Funktionsaufrufen ne, also die Entscheidung entweder oder beispielsweise genau, also das wäre für mich jetzt auf jeden Fall so ein Punkt. Der finde ich auch sehr wichtig.
Ja, also dass man quasi sagt, es gibt eine ganz klare Verantwortlichkeit, die von dieser Funktion übernommen wird, so könnte man es ja denn eigentlich zusammenfassen, oder? Also genau genau das ist wirklich eine Aufgabe, gibt, die total klar ist. Genau das werde ich auf jeden Fall so Punkt 1, wenn wir das noch mal so ein bisschen in so ein paar Punkte zusammenfassen, finde ich sehr gut. Beziehungsweise lassen wir sagen Punkt 2. Wir nehmen nochmal den ersten mit den Namen auf.
Finde ich gut. Da kommt nämlich auch gleich noch ein nächster Punkt, der mir auch sehr wichtig ist, den ich aber, wo ich selbst oft in Fallen laufe, weil es halt bequem ist, sich nicht. Dran zu halten. OK, jetzt kommt bin gespannt ist die Anzahl der Eingabeparameter bei Funktionen und es ist leicht zu sagen Na ja dann geb ich das noch rein und das aber es muss denn jetzt die Funktion an jetzt muss ich ja noch wie du meintest zum Beispiel.
Entscheidungen treffen innerhalb der Funktion, ja, wann etwas passiert. Na ja gut, dann gebe ich jetzt von außen rein, ein Parameter, der mir hilft diese Entscheidung zu treffen und dann ist halt einfach schon wieder. Vorsicht geboten, weil das zeigt schon wieder, dass diese Funktion mehr als nur eine Verantwortlichkeit hat und man eigentlich dann schon wieder aus seinem cleancode Rahmen, den man sich gesteckt hat, Rausspringt und.
Die Komplexität, eine Funktion zu verstehen oder auch sauber zu entwickeln, steigt enorm an. Mit der Anzahl der der Eingabeparameter. Das klingt jetzt irgendwie so n bisschen ach na ja, komm, ob ich jetzt einen hab oder 2 oder 3. Das so schlimm ist das jetzt nicht.
Ja, das wirkt erstmal nicht schlimm, aber rückblickend und über die ganzen Iterationen, wir haben ja auch schon viel über Refactoring gesprochen, hilft es einfach nicht, viele Eingabeparameter zu verwenden beim Codeverständnis später. Sondern. OK, hier gehen 3 Parameter rein.
OK wo war OK die erste der erste verstehe ich noch mit dem passiert was was macht der zweite OK der entscheidet irgendwie was mit dem ersten passiert, der Dritte im im Worst Case ist der Dritte sogar noch ein Fleck einfach sowas wieso? Optionaler Schritt ist an oder aus auch ein ganz klassisches Beispiel Fleckparameter und muss ich sagen, neige ich auch dazu, die ab und zu mal wenn es schnell gehen muss einzubauen und denk mir immer wieder nicht cool nicht.
Cool. Aber es passiert, also weißt du was ich meine mit Fleckparametern definitiv. Also das ist ja quasi also das, das geht ja sogar auch n bisschen das Hand in Hand so n bisschen mit der mit.
Sage ich jetzt mal Verantwortung, die eine Funktion übernimmt, dass man sagt, OK, es soll wirklich nur eine Aufgabe erfüllen und ein Beispiel wäre ja im Sinne von Hand in Hand gehen, wäre ja, dass man zum Beispiel sagt, Braten oder mixen, und du gibst sozusagen Fleck von außen rein und sagst quasi Braten gleich True, und in dem Fall sagst du dann für den Fall, dass Braten gleich Choice führe ich braten aus, sozusagen also den Code für Braten, weißt du, und das ist ja quasi so ein
bisschen. Der Punkt, der da Hand in Hand geht, meiner Meinung nach. Aber es gibt natürlich auch andere Möglichkeiten, wie zum Beispiel so sogenannte Magic Numbers, sag ich jetzt mal. In dem Fall ist es n Magic Number Set, weil du jetzt vielleicht sagen, du gibst irgendwie von außen ne zahlen inam oder was auch immer rein, was dir anhand von diesem Inam dann am Ende bestimmt, welcher Code ausgeführt wird. Genau, ich weiß was du meinst
und das Ding ist man. Es ist ja immer einfach gesagt, dass man sich denkt, ja Pass auf, gib bitte nicht zu viele Parameter rein und gib auch nicht solche Flex rein, so eine Parameterflex oder wie man das auch mal nennen mag Feature Flex wie auch immer, gibt die Mal bitte jetzt nicht von von außen rein und das ist ganz klar, das macht ja auch Sinn, man kann darüber reden, man denkt sich es ist logisch und dann implementierst du eine Funktion und Voila auf einmal hat sich
sowas eingeschlichen, obwohl man ja eigentlich weiß, dass man sowas nicht haben möchte und dann auf einmal ist es doch so und das ist manchmal so ein bisschen, dass man sich denkt, so wo kommst du denn her? Du kleiner Scheu, so rückblickend, so richtig reingesneckt und du denkst dir so hä so Wochen später, warum? Ich weiß doch selbst ganz genau, dass das nicht gut ist. Warum habe ich das gemacht und
ich finde, da muss man auch. So offen und ehrlich sein auch, liebe Zuhörer, lieber Zuhörer dir gegenüber, dass sowas passiert. Also ich sag das ja nicht ohne Grund, also diese Fleckparameter zum Beispiel hab ich echt ab und zu noch drin, wo ich mir denke, warum mach ich das ja gut, weil es an der Stelle einfach. Bequem war eine Entscheidung,
darauf basierend zu treffen. Und. Es natürlich Aufwand und Kraft kostet, das Umzudesignen, was ja auch wieder ne Form von Refactoring ist, was da einfach, wenn man ehrlich ist und wirklich clean entwickeln will noch ausstehend ist, ja. Out genau, es ist einfach out, verkürzen wir das ganze. Und ja, und deswegen, was ist denn für dich so eine Anzahl an Parametern wo du sagst, das ist das ist für dich persönlich noch cool? Also ich würde sagen irgendwas bis 2 ist auf jeden Fall.
Geht absolut klar. 3 ist okay gehen irgendwie noch, ist aber finde ich schon so eher grenzvoll. Also dass man wirklich sagen muss, okay brauche ich wirklich diese 3. Kann ich das noch irgendwie anders machen und wenn nein, dann ist es okay. Aber wenn man jetzt zum Beispiel, also ich find 4 Parameter, da wird es dann schon langsam so n bisschen kritisch
bei einer Funktion, weil. Genau aus den Gründen oder weil du es einfach so. Also von der Optik her nicht Marx vom vom Lesen Diskurs. Oder hast du wirklich das Gefühl bei 4 Parametern, dass es, dass die Komplexität zu groß wird? Ja genau, also ist so meine Erfahrung. Dass es halt so ist, weil du allein schon.
Also es geht ja auch nicht immer nur darum, wie eine Funktion geschrieben aussieht, sondern wenn du so ne Funktion aufrufst, dann ist ja auch immer die Frage OK, was für Parameter brauch ich, du brauchst ja im Endeffekt relativ viele Informationen, die du in eine Funktion hineingeben musst, um dann zu sagen okay was passiert denn damit, also du musst ja auch diese ganzen Informationen zusammen sammeln, sage ich jetzt mal.
Und im Normalfall, wenn du 4 Parameter brauchst, dann brauchst du von außen noch 4 Werte, die du irgendwoher kriegst. Und die Frage ist, wo kriegst du die her? Das ist auch wieder am Ende alles Code jetzt mal ein bisschen blöd gesagt. Und deswegen, je mehr Parameter also irgendwann so ab über 3 sollte man vielleicht schon mal noch mal ein bisschen gucken.
Also es ist jetzt nicht so, dass ich sage, bei 4 Parametern musst du was anders machen, es gibt durchaus auch libraries oder so, wo du halt mehrere Parameter hast und auch mehr als 4. Kennt man bestimmt, wenn man ein bisschen auch Libraries benutzt hat und damit gecode hat. Aber nichtsdestotrotz ist es vielleicht schon, würde ich so als andere. Punkt sagen bei mehr als 3 muss man schon mal noch mal vielleicht noch mal gucken, ob man da nicht leichtfertig handelt. Ja, wie sieht es bei dir?
Ja, geh ich mit auf jeden Fall. Also ich sag mal so nach best practice oder so sollte man halt immer gucken, dass die Funktion nur ein Eingabeparameter haben, dass man halt wirklich sagt, OK, diese Funktion hat ein Eingabeparameter und dann passiert also anhand des Namens erkenne ich schon was damit passiert sozusagen alles alles klar, dass es nach Lehrbuch so sein sollte, aber ich bin ganz bei dir, es geht halt schnell, dass du mehr brauchst und dann fragst du dich wieder.
Ist das jetzt okay 34? Ab 4 finde ich dann halt auch schon tricky. Was aber noch spannend ist, jetzt können ja Leute sagen, na gut, dann mache ich in manchen Sprachen geht das und manchen nicht, aber gehen wir mal davon aus, wir sind jetzt in dem Fall, ich habe jetzt optionale
Parameter, oder? Parameterlisten, was ja auch, sage ich mal, ein ähnliches Verhältnis, dass ich quasi, ich muss die Parameter jetzt nicht angeben, aber ich kann ansonsten gibt es oder oder, es gibt so die Default Werte dann wenn ich
sie nicht angebe. Löst das das Problem, dass man dann sagen kann, OK, na gut, dann kann ich ja jetzt 8 haben, weil 2 davon sind nur Pflicht, die anderen sind default belegt und wenn ich Bock hab was zu ändern da dran, dann kann ich die belegen wie wie stehst du denn da zu dem Thema?
Na du kannst ja also optionale Parameter ist halt schwierig, also aus Erfahrung kann ich sagen, manchmal ist es schon nicht schlecht, wenn man solche Parameter hat, also angenommen man hat zum Beispiel eine Funktion mit einem Parameter und hat vielleicht noch einen optionalen zweiten, da geht es halt wieder dahin so okay wenn du irgendwann keine Ahnung 10 Parameter hast und 2 davon sind mandatory, also verpflichtend die einzusetzen. 8 davon sind halt freiwillig.
Optional freiwillig klingt gut, freiwillig. Dann ist es halt auch wieder die Frage okay warum hast du 10 Parameter für deine Funktion, auch wenn sie nur optional sind, aber du kannst sie ja benutzen, das ist immer so ein bisschen dann die Frage und dann ist halt auch wieder die Frage okay wenn diese Parameter wirklich vielleicht auch zusammengehören und eine Einheit bilden, was? Gibt es nicht ein Objekt, was quasi diese ganzen Parameter als Attribute enthält?
Und dann übergibst du halt das Objekt ne andere Punkt. Andererseits würde ich mich halt auch hinstellen und sagen, ja gut, du kannst jetzt aber nicht zum Beispiel weiß nicht 5 Parameter nehmen, die miteinander eigentlich so gut wie gar nichts zu tun haben, also sowas wie keine Ahnung so mehrere Flex wo du sagst das ja nein das ja nein das ja nein so nach dem Motto und dann noch keine Ahnung so wirklich Parameter die am Ende wirklich also verpflichtend sind, die du
auf jeden Fall einsetzen musst. Die dann so ich sag mal wirklich Daten enthalten, die also so payload sozusagen, wenn.
So n so n Mischmasch aus Informationen hast, dann bringt es aber auch zum Beispiel nicht zu sagen, ja gut, dann verwurschtel das doch alles in Objekte und Übergib ein Objekt, weil dann hast du ja einen Parameter, das ist ja dann wie das Safe so, weil dann hast du ja noch einen weißt du also es muss natürlich immer einheitlich logisch zusammenpassen, wenn man sagt, OK, man erzeugt quasi ein Objekt mit Attributen und dann kann es aber durchaus helfen, auch für die Lesbarkeit einer
Funktion, dass man sagt okay, ich habe zum Beispiel 3 Parameter, ich möchte jetzt aber nur noch 2 haben, weil 2 Parameter ist eigentlich mehr oder weniger logisch eine Einheit. Kannst du halt als einzelnes Objekt übergeben und damit hast du dann quasi eventuell wieder 2 Parameter die du übergibst. Ein Objekt und eine Variable zum Beispiel ein ein, ein Datenwert was ich in String was auch immer. Und damit kannst du dann
weiterarbeiten. Es ist am Ende auf jeden Fall lesbarer, als wenn man jetzt zum Beispiel alles total aufschlüsselt und sagt, also genauso umgekehrt, wenn du n Objekt hast, kannst du natürlich auch sagen, gut, ich übergeb jetzt beispielsweise von einem Objekt immer nur die einzelnen Parameter. Und Übergeb anstatt ein Objekt alle Attribute des Objektes. Aber dann hast du natürlich wieder viele Parameter, was mich mal zu viel interessieren würde,
da könnte ich auch mal eine. Frage an dich mal zurück werfen und zwar wie stehst du denn dazu wenn man sagt okay man hat. Zum Beispiel? Du hast ein Objekt und 3 Attribute. Übergibst du dann die Attribute einzeln oder übergibst du das gesamte Objekt? Merk dir die Frage mal ganz kurz. Ich würd gern noch mal zusammenfassen, was davor war, was du, weil du hast jetzt sehr sehr viel geilen Input geliefert, ich würd das noch mal ganz kurz noch mal zusammenfassen. OK, also.
Sind wir eigentlich jetzt, wenn ich das richtig verstanden habe, beide der Meinung, dass optionale Parameter OK sind? Klar, die haben ihre Daseinsberechtigung, genauso argumentenlisten. Zählen aber in die Gesamtheit der Parameter, die man übergibt mit rein.
Das heißt wenn ich jetzt 2 mandatory wie du gesagt hast und einen optionalen habe, dann ist das noch okay, aber das geht schon in Richtung Grenze und kann nicht sagen ich habe 2 die Pflicht sind, dann habe ich also 2 eingabeparameter und kann so viel verkehrten da hinten dran optional wie ich will, weil das eben genau die Komplexität der Funktion trotzdem enorm steigert, weil man ja sowas machen muss wie ja ist denn dieser Parameter gesetzt, ist der definiert oder ist das noch
der Default wert oder weißt du also dadurch? Steigert ja die Komplexität oder wird die Komplexität enorm gesteigert innerhalb der Funktion? Also da bin ich auf jeden Fall ganz bei dir, das mit den Objekten zusammenfassend semantisch finde ich ist sehr sehr gut, der Punkt, wenn das nämlich wenn du eine Datenstruktur bauen kannst, die semantische super zusammenpacken, dann kannst du die übergeben auf jeden Fall das. Weil es einfach dadurch wieder
lesbarer wird. Und dann komm ich ja jetzt im Prinzip zu deiner Frage, ob ich die ob das Objekt übergeben würde oder die einzelnen Werte aus dem Objekt. Richtig also ich hab jetzt n Objekt mit 3 Attributen und kann diese Attribute einzeln haben, ob ich jetzt ZB. Ja, weiß ich nicht. Wir haben eine Person als Objekt und das hatten die Person hat Name, Alter und so weiter und du sagst übergibst du jetzt die Person das Objekt in eine Funktion, zum Beispiel ist volljährig mal auf Deutsch,
jetzt kurz. Ob ich die Person rein gebe oder zum Beispiel nur das Alter, also an der Stelle wäre halt auch noch interessant, dass du zum Beispiel ein Objekt hast, was vielleicht 10 Attribute hat. Du brauchst aber nur 2 oder 3 oder was auch immer, so weißt du also du brauchst nur eine deutliche Teilmenge davon, genau also wenn es, wenn es wirklich nur einige Werte sind davon, dann würde ich immer die Werte übergeben, weil es einfach viel klarer ist, was die Funktion
macht. Also wenn ich nur Funktion habe wo eine Person reingibt geht oder also um bei dem bei dem Beispiel zu bleiben, dann kann er ja immer noch alles Mögliche drin passieren. Wenn ich aber das Alter rein gebe weiß ich ja schon, dass die Funktion irgendwie mit dem Alter
arbeitet. Ja. Andererseits, also ja, verstehe ich auch, gehe ich auch soweit mit was ich halt interessant finde ist, wenn du jetzt dieses Beispiel ist volljährig nimmst, ist es ja schon an sich schön zu lesen, wenn Du zum Beispiel sagst ist volljährig und dann gibst du quasi zum Beispiel die Person rein, also Person x. Also ist die Person X volljährig sozusagen oder ist das Alter volljährig? Also weißt du, wenn du jetzt zum Beispiel nur das Alter dieser Person in diese Funktion rein
gibst. Lesbar ist es auf jeden Fall theoretisch in an der Stelle ja schon. Sag ich jetzt mal einfach nur vom optischen her, dass man vielleicht sagt, ist diese Person volljährig, so nach dem Motto, oder? Ist dieses Alter volljährig, weißt du das? Das wäre noch so n kleiner. Ich weiß worauf du hinaus willst.
Da ist natürlich die Frage, wie der Code davor aussieht, wenn ich jetzt eine variable x habe und da steht das Alter drin, ich gebe das rein, dann weiß ich halt nicht warum gebe ich jetzt in diese Funktion ist volljährig x rein, wenn ich jetzt aber zum Beispiel die die Person habe und mir dann das Alter daraus ziehe, dann sehe ich ja wieder den Bezug zur Person, Person, Punkt, Alter, sozusagen zum Beispiel oder oder die Variable heißt
halt irgendwie alte, also wir verzetteln uns vielleicht ein bisschen, ich will das jetzt nicht zu extrem machen. Dass du halt am Variablennamen schon erkennst, dass es sich um das Alter von Personen sowieso handelt. Noch schöner ist natürlich, wenn du aus der Person das Alter ziehst und das Übergibst liegt aber einfach daran, dass ich du kannst. Klar kannst du das Ganze, die das ganze Objekt da reingeben, aber was ist zum Beispiel?
Wenn jetzt im Objekt sich was ändert, du du das Alter woanders herbekommst. Das ist jetzt ein sehr minimalistisches Beispiel, aber angenommen irgendwie, die Struktur ändert sich, dann ist deine Funktion nicht mehr autark da drin. Wenn du jetzt sagst ich geb aber das Alter rein, dann wird es immer von außen das Alter geben und die Funktion kann damit arbeiten und ich muss nicht die Implementierung wie ich an das Alter in dem Objekt rankomme
innerhalb der Funktion ändern. Also wie gesagt man merkt das ist immer so ein für und wider, das heißt es immer die Frage wie der Code drumrum aussieht. Ja, aber es ist sehr interessant, dass wir einfach mal drüber gesprochen haben, weil das sind ja interessante Gedanken, die wahrscheinlich. Nicht nur wir an so einer Stelle haben, sondern sich vielleicht schon die ein oder andere Person auch schon gefragt. Hat auf jeden Fall und man hört auch nicht auf sich das.
Das ist auch ein sehr guter Punkt. Ja, ich würde sagen paar Punkte, so ein 2 kriegen wir auf jeden Fall noch zusammen. Ja, zu den Parametern hätte ich noch einen Punkt, weil das hat mich sehr lange begleitet in meiner Software entwicklungskarriere nenne ich es mal. Und zwar Eingabeparameter als Output verwenden. Ich hoffe du kannst mir folgen,
wenn ich. Das ist also, warum ich das so lange begleitet hat in in der Embedded Welt habe ich ein C entwickelt und da war das schon sehr oft so, dass du Referenzen rein gibst in die Funktion innerhalb der Funktion, was damit passiert und du quasi dann ja dieses die die Referenz verändert im Endeffekt, das heißt, so gesehen ist der Eingabeparameter auch gleichzeitig dein Output, weil dein Ergebnis da drin steht oder noch besser du gibst ein Eingabeparameter rein. Und sagt, schreibt mir den
Output da rein. Ja, ja, ich. Ich weiß was oft hinaus. Und dass das sind das sind Konstrukte, die auf jeden Fall vorkommen, aber auch enorm die Komplexität steigern, weil du dann genau gucken musst. Also erstmal ist die wird die Benahmung noch schwieriger und du musst gucken, was passiert jetzt wirklich da drin und wo steht mein Ergebnis und wie kann ich das weiterverarbeiten. Aber das ist zum Beispiel. C haben wir das oft so gemacht, dass es weiß nicht ist auch schon ne Weile her.
Ich weiß nicht, ob es immer noch so gemacht wird, ich will mich da jetzt nicht zu weit, ich bin da schon ne Weile raus, aber dass du quasi nen ein Rückgabewert hast zum Beispiel ne Art bootisches Konstrukt, weil den Booleschen Datentyp gibt es ja nicht im C. Aber zum Beispiel dir irgendwas gebaut hast, was signalisiert, ob das jetzt erfolgreich oder nicht war und dann in diesem Eingabeparameter zum Beispiel pointer dann dein Ergebnis drin stand.
Also du sagst es war erfolgreich und das Ergebnis steht in dieser Eingabevariable das waren so Konstrukte, die auf jeden Fall gang und gäbe waren. Aber auch eine enorme Komplexität da reinbringen. Nur mal um das so aus einem anderen Bereich mal mit hinzuzufügen, finde ich, es war valide, das zu machen, ich habe es auch gemacht, aber es steigert auch enorm die Komplexität.
Also ich finde, das ist irgendwie ein interessanter Punkt, weil ich verstehe, wieso man das zum Beispiel auch im Embedded Bereich macht, um halt eben auch möglichst Speicherplatz zu sparen, weil du ja vielleicht auch. Im Endeffekt bei beim Anlegen von neuen Variablen eben halt auch neuen Speicher allokierst und benutzt sozusagen.
Das ist das, das verstehe ich. Es ist natürlich auch wieder ein bisschen ein zweischneidiges Schwert, weil wenn wir jetzt kann man auch vielleicht eine ganz gute Überleitung vielleicht kriegen, zu einem neu, zu einem anderen Punkt, also zu dem
vierten Punkt quasi. Und das wären sozusagen das keine Seiteneffekte Auftreten bei der implementarspanner Funktion, weil im Endeffekt kann es ja durchaus sein, dass du zum Beispiel ne Funktion aufrufst und erwartest, dass der Input nicht gleich der Output ist, dass du eben nicht diese Referenz hast, dass du sozusagen mit der Variable, die du rein gibst in die Funktion danach nicht mehr quasi, also dass sozusagen diese Variable sich nicht verändert, sondern nur der
Output sozusagen verändert. Und wenn du den Output wieder auf die Variable zeigen. Ist dann OK, ist ja klar, dann überschreibst du sozusagen den Wert der Variable.
Aber wenn du jetzt zum Beispiel ne dir ne andere Variable nimmst, also zum Beispiel X berechnest und x ist zum Beispiel du gibst x rein und x ist 5 und du kriegst sozusagen eine 3 raus und speichert die 3 in Y und erwartest jetzt danach, dass Y zum Beispiel. Immer noch ist und ne x ist immer noch 5 und y ist 3 ne. Also das was sozusagen von der Funktion zurückkam. Und am Ende hast du aber dadurch, dass du ne Referenz hast, auch den Wert von x geändert und dann ist x und y beides 3.
So und das ist ja irgendwie ne gewisse Art von Seiteneffekt, die du erzeugen kannst dadurch. Die laut Cleancode im optimalen Fall auch nicht auftreten soll. Genauso weiß ich, fallen dir noch andere Beispiele von von Seiteneffekten ein. Beispiel konstruieren ist immer nicht so einfach aus dem Stand was, was auf jeden Fall ein guter Punkt war, ist dieses ganze Call by Reference und Callby Value Probleme was du geschildert hast. Man muss ja gar nicht so weit
gehen, das kann ja auch sein. Du hast eine Klasse und verwendest Funktionen dieser Klasse und sagst sowas zum Beispiel. Set X oder so nochmals Beispiel und es muss ja nicht mal unbedingt ein Referenzproblem
sein, dass du halt quasi. Keine echte Kopie hast, sondern halt die Referenz. Veränderst da drin und dadurch seiteneffekte hast, sondern was ist, wenn innerhalb deiner Klassenfunktion oder Methoden du sagst OK die Funktion wird aufgerufen, ich mach was die Funktion soll, aber Moment mal, wenn das passiert, dann muss ich ja eigentlich hier die Variablen
und so anpassen. Mir fällt jetzt gerade kein einfaches Beispiel ein, aber ich hoffe, man kann es trotzdem verstehen und innerhalb deiner Implementierung änderst du andere Klassen. Variablen ab oder gehen wir von Klassen weg? Du hast irgendwelche globalen Variablen, die sich dann anpassen und dieses, das sind ja auch Seiteneffekte oder Side Effects.
Darauf wollte ich eigentlich mit der Frage hinaus, weil ich wusste irgendwie intuitiv, dass du auch auf globale Variablen irgendwie hinaus kommst und deswegen, das war eigentlich so mein Ursprungs, du kennst mich so gut. Weil ich halt nur mit globalen Variablen arbeite. Und die immer veränderst. Und die funktionieren. Aber das ist halt klingt immer so nach. Warum sollte ich sowas tun, aber sowas kann sich einschleichen und dann fragst du dich auf einmal was.
Passiert hier, warum geht das nicht? Was also es muss doch gehen, was ich hier quasi die Funktion die ich aufrufe, da kann doch nicht irgendwas anderes rauskommen als
erwartet. Ja, aber bei so einer Seiteneffekte können halt einfach auch schnell entstehen, das stimmt, das ist halt auch immer noch ein guter Punkt, dass man halt wirklich seine Funktion darauf checkt und überprüft und notfalls halt refectert, falls denn so eine Seiteneffekte auftreten können, weil das Macht, das Macht die Welt nur unfassbar schwierig in Zukunft. Ja, das stimmt.
Wenn man ganz blöde Frage noch mal, wenn man jetzt sagt okay man soll jetzt zum Beispiel vielleicht nicht globale Variablen verändern oder keine Membervariablen verändern. Wie weit kann man denn zum Beispiel sagen? Ja gut, aber du hast ja member Variablen innerhalb des Objektes. Wenn du eine Funktion aufrufst, dann kann es ja durchaus sein, dass du member Variablen veränderst. Zum Beispiel war Geta und Setter
oder was auch immer. Ja, also mir ist doch ein Beispiel eingefallen, wo man sowas ja macht kann. Angenommen du baust dir eine Art. Datenstruktur wie eine Liste beispielsweise gehen wir mal davon aus, die gibt es nicht, oder oder wir können auch die normale Liste nehmen und wenn nur ein Element hinzufügst. Dann wird ja ne Funktion die dir die Größe der Liste ausgibt,
danach was anderes zurückgeben. Also beispielsweise du sagst sowas wie n at beispielsweise fügst n Objekt hinzu in deine Liste, dann wird ja. Lanksize wie auch immer die Funktion dann heißen soll, dir plus 1 quasi zurückgeben, also ein Element mehr als vor deinem at. So, da kannst du ja sagen, ja, das ist ja jetzt schon auch n seiteneffekt. Ja. Weil ich hab n Elemente hinzugefügt und auf einmal ist
die Liste 1 länger oder was? Aber das ist ja quasi gewünscht, also das ist ja logisch im Prinzip, wenn du sagst wenn ich etwas hinzufügen möchte ich, dass die Gesamtlänge ja natürlich auch 1 größer ist. Also das würde ich jetzt nicht so als unerwünschten Zeiteffekte.
Aber deswegen wollt ich das noch mal kurz abgrenzen, weil das ja wirklich glaub ich interessant ist, weil wenn man zum Beispiel sagt, also es ist keine Regel zu sagen, verändere bloß nicht globale Variablen oder Membervariablen sozusagen ne eines Objektes beispielsweise. Aber es ist ja schon wichtig zu überprüfen, OK, mach ich hier auch wirklich das, was ich vorgebe zu tun oder sneak ich da jetzt noch so n paar versteckte Easter Eggs mit rein? Schöne Fallen für.
Andere Entwickler aus dem Team genau.
Also wenn ich jetzt zum Beispiel noch mal kurz auf das Kochen Beispiel Zurückgebe und wir beide haben zum Beispiel irgendwie keine Ahnung, uns vorher einen kleinen Code abgemacht beim Kochen und ich sag ja Tino, gib mir doch mal die mandarine und du gibst mir auf einmal keine Ahnung die Pilze, dann wäre das für alle anderen natürlich so ein was ich denke er soll die Mandarine geben, dem jetzt die Pilze so also das ist natürlich Verwirrung, die halt immer nicht
nicht sinnvoll sind, weil wir im Vorfeld gesagt haben mandarine. Pilze ja ja genau ne, aber genau, wir können halt also die Analogie mit dem Kochen ist ja super, das ist ja genauso als wenn du sagst. Füge Salz hinzu und die Funktion sagt ne Prise Salz, ne Prise Pfeffer genau und du denkst dir okay warum ist es jetzt pfeffrig? Ich hab da nur Salz hinzugefügt oder oder noch besser Salz und Zucker. Du denkst also was passiert hier und Salz und Salz genau genau und das ist Sau salzig und
gleichzeitig total süß. Tolles Gericht und das war auch das letzte Mal, dass du gekocht hast. Na ja, aber das ist ja die Analogie, ist cool, da kann man das, glaube ich mit den Side Effects ganz gut verstehen. Mit den Salt Effects, ja. Source Code effects. Ist niemals Salt Effect. Ja, und ein Punkt, der noch
wichtig ist. Für uns vor allem, weil wir haben es auch sehr oft thematisiert, schon in unserem Grundlagenkurs und auch hier im Podcast ist beim Entwickeln einer Funktion, und das ist jetzt Punkt 456, das müsste jetzt 5 sein, 5 sein ist für mich jetzt.
Zudem würde ich jetzt noch anbringen, ja, dass man Test schreiben kann, dass die Funktion, da sind sie wieder die Tests und im Prinzip hast du mich rausgebracht, da sind sie wieder, die Test. Dass man die Funktion dementsprechend auch entwickelt, dass es gut testbar ist.
Und da spielen die ganzen. Punkte, die wir vorher quasi besprochen haben mit rein, weil je weniger ich darauf achte, umso schwieriger wird es, diese Funktion abzutesten und wir wollen aber die Funktion gut abtesten, um einfach eine Gesamtsoftware zu erreichen, die wirklich clean ist und. Ja, sage ich mal, gut entwickelt ist funktional.
Richtig ist, das klingt jetzt immer ein bisschen hochtragend, weil was ist funktional richtig, Bugs gibt es gefühlt immer, aber dass wir halt so wenig wie möglich Bugs drin haben, sage ich mal, weil wir eine hohe Temperatur haben. Am Ende ja, weil alles gut, gut abgetestet ist. Klar, es gibt immer Testfälle, an die man nicht denkt, in dem Moment, dann fällt das auf, dann kann man den Test nachziehen und so weiter. Aber es ist halt schon enorm wichtig, Funktionen gut abtesten zu können.
Und ich finde. Also Side Effekt Salt Effects wie wir gerade festgestellt haben machen testen sehr
schwierig. Parameter viele Parameter machen Tests schwierig, weil ich muss natürlich einfach, also man kann sich das ja relativ einfach vor Augen führen, für jeden Parameter der, den ich quasi einer Funktion hinzufüge als Eingabeparameter. Je mehr Tests muss ich schreiben, weil ich muss ja die einzelnen Möglichkeiten des Parameters abtesten richtig, mal vereinfacht gesagt, das heißt, allein die Testkomplexität steigt enorm an mit der Anzahl
der Parameter, ja. Und alleine wenn man jetzt zum Beispiel mal noch mal um ganz kurz noch mal die Analogie zu zum Kochen herzustellen, weil wir heute so schön dabei sind, wenn du zum Beispiel sagst, du schreibst eine Funktion, die heißt Salze mir das Essen ne und du salzt das Essen und schmeckst es danach ab, abschmecken, ist jetzt der Test. Dann kannst du ja relativ gut für diesen einen Testfall
prüfen. Ist es jetzt salzig genug und dann fängst du an und sagst, bitte füge noch ein paar Kräuter hinzu, wie zum Beispiel füge Oregano hinzu, so dann schmeckst du das ab und sagst okay das passt auch so, aber wenn du jetzt zum Beispiel sagst, die Funktion heißt Würze mein Essen und du Schüttest da Salz rein und Kräuter und Paprikapulver und noch Knoblauch und alles. So warte mal Paprikapulver. Immer ebelsüß. Dann ist es ja also, wie willst
du dann abschmecken? Also du kannst natürlich auch abschmecken und gucken ob das Gesamtkonstrukt passt, aber du wirst ja zum Beispiel danach, wenn du sagst okay es ist noch nicht salzig genug, dann fängst du ja nicht an zu sagen, ja gut, jetzt haue ich quasi noch mal die ganze Gewürzmischung drauf, die ich gerade drauf geballert habe, sondern du versuchst. Natürlich einzelne Punkte abzutesten, also zum Beispiel nur das Salzen, in dem Fall sozusagen.
Und wenn du das einzeln quasi generell über die Funktion kapselst und auch einzeln abtesten kannst. Dann ist das natürlich das Ganze am Ende auch testbarer, was ja auch wichtig ist, ne. Ja, super zusammengefasst. Auf jeden Fall find ich sehr gut. Danke dafür nochmal. Ich würde sagen, wir haben eigentlich auch viele Punkte jetzt genannt, bei weitem nicht alle. Da gibt es bestimmt auch noch Punkte, die wir jetzt gerade übersehen.
Einen letzten hätte ich noch, weil das ist ein Thema, was ich auch sehr oft diskutiert habe schon und ich würde es aber auch sehr kurz fassen, weil das ist halt schon da kann man eine Weile drüber reden und vielleicht gibt es auch andere Ansichten, aber. Ich bin gespannt. Ob. Das Thema Dokumentation im Sinne von Kommentare innerhalb einer Funktion OK, und das möchte ich ganz kurz und knapp fassen, weil ich habe das in mehreren Projekten schon unterschiedlich handhaben müssen mit.
Hatte ich glaube ich auch mal erwähnt. So jede Zeile Code sollte einen Kommentar haben um zu erklären was da passiert, wo ich mir denke OK ist der Code so schlecht, dass es nicht verständlich ist, was in dieser einen Zeile Code passiert, weil das ist nämlich genau der Keypoint. Code sollte selbst also selbsterklärend sein, ansonsten ist er wahrscheinlich nicht gut geschrieben und sollte es notwendig sein, n Kommentar ran zu machen, dann bitte nur unter der Prämisse, dass es nicht
schlecht strukturierten Code oder schlecht geschriebenen Code erklärt. So nach dem Motto Ich weiß, man versteht nicht was hier passiert, aber ich erkläre es dir kurz in einer Zeile, das ist halt absolut Bad Practice, nenne ich jetzt mal. Wenn es aber vielleicht wirklich sehr komplex ist oder vielleicht irgend. Wissen vorausgesetzt, wird an der Stelle, was vielleicht nicht so so trivial ist. Auf dieser einen Zeile oder innerhalb dieser einen Funktion um Gottes Willen.
Klar kann man Kommentare schreiben, aber ich finde, es darf niemals als Grund genannt werden, ja, damit man versteht, was innerhalb dieser Funktion passiert. Ja, das ist ein guter Punkt. Gehe ich definitiv mit im Endeffekt. Ist es immer nicht schlecht?
Ich nicht nicht zu sagen, ja, das geht aber nicht ohne Kommentar, sondern eher erst mal die Frage stellen, wie kann ich den Code schreiben, dass es also, dass es vielleicht auch ohne Kommentar geht, ne wie gesagt ich, ich würd auch sagen wenn es zu komplex und manchmal gibt es ja wirklich sehr komplexe Sachen, die du auch wirklich vielleicht sehr mathematisch auch irgendwie erklärst.
Dann kann man vielleicht mal einen Kommentar dranpacken, obwohl natürlich auch wiederum der Funktionsname und das, was in dieser Funktion passiert. Kapselt sein sollte, dass der Funktionsname ausreichend sein sollte für die Erklärung von
dem, was im Code passiert. Ja, aber so n Beispiel ist, du hast zum Beispiel ne Konstante. Weil du gerade meintest, mathematisch physikalisch, wo einfach vielleicht erklärt ist, warum diese Konstante wichtig ist oder so einfach mal so ne so ne Erklärung für diesen einen festen Wert beispielsweise, da würd ich sagen, OK, cool erklärt noch mal warum jetzt da so ne Konstante entwickelt wurde, wenn es jetzt nicht gerade peace oder so was fast jeder kennt, aber also weiß worauf ich hinaus
möchte, da finde ich ist das denn ein Fall okay bei pi weiß man ja, dass es 3 ist, genau exakt 3. Es tut mir leid, dass es soweit. Keiner weiß es. Hast du sehr gut noch mal sehr gut noch mal zusammengefasst. Ja, dann würde ich einfach noch mal kurz alle Punkte einmal kurz nennen, die wir und also die wir durchgegangen sind und die auch vielleicht noch mal als Zusammenfassung. Für das Paket zusammen und dann ab nach Hause.
Ja, vielleicht noch mal Zusammenfassung für dich, lieber Zuhörer, liebe Zuhörerin, auch noch mal interessant sind also als ersten Punkt, der wirklich wichtig wäre, wenn man Funktionen schreibt, achte doch bitte drauf und versucht daran
zu denken, dass. Aussagekräftige Namen sein sollen und dass es auch kurze und prägnante Namen sein sollen für die Benahmung der Funktion. Was wir am Anfang gesagt hatten, dann ist es wichtig, dass es wirklich ne ein eindeutige Verantwortlichkeit hat, also entweder mixen oder kochen und nicht mixen oder kochen, eine Funktion quasi benannt wird und damit halt auch das da drin quasi nicht beides tut.
Dann sollten sollte man darauf achten, dass es eine minimale Anzahl von Parametern gibt, also nicht übermäßig viele hinzufügen, wenn es nicht unbedingt sein muss, wirklich genau darüber nachdenken. Auch darauf achten, dass nicht unerwünschte Side Effects oder Salt Effects, wie wir es genannt haben, stattfinden. Also wenn du dein erstes Side später der Side seiner Wunder genau wenn du dein Essen salzt, sollte nicht noch Zucker dazukommen. Das war Punkt 4.5. Ist achtet darauf.
Dass sozusagen du auch Tests dazu schreibst und auch das. Sagen deine Funktion möglichst testbar ist Testbar geschrieben ist und Punkt 6 Dokumentation, also ein der Code sollte sich im optimalen Fall immer selbst erklären und Kommentare sollten im Normalfall eigentlich wirklich eine absolute Ausnahme sein und mit diesen 6 Punkten kann man auf jeden Fall schon mal einiges anfangen und ich hoffe das waren alle. Weil es war. Also ich.
Das waren das waren die 6 Punkte, die wir Überblick hast. Da bin ich mir sehr sicher. Und wie gesagt, was uns auf jeden Fall interessieren würde ist, wir haben auf jeden Fall nicht alle Punkte besprochen, die jetzt irgendwie Thema von Cleancode im Bereich Funktionen sind.
Wenn ihr noch was einfällt, was wir vergessen haben, was wir jetzt nicht besprochen haben, dann schreibt uns doch einfach mal bei Instagram oder auf unser Podcast Mail die links zu den beiden Sachen und auch zu allen anderen Plattformen, wo wir unterwegs sind, findest du in den Show Notes und in dem Sinne würde ich noch abschließend sagen, wenn dir die Folge gefallen hat, dann lass ein Like da. Empfehle auch gerne als kleine Hausaufgabe 2.
Deinen Freundinnen, Freunden, Arbeitskollegen, was auch immer, wo du dich gerade aufhältst, unseren Podcast. Ja, und in diesem Sinne würde ich sagen, wir wünschen dir noch einen schönen Tag und wir hören uns beim nächsten Mal wieder. Deine Coding Buddies gemeinsam besser. Was?