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?