Latest / Coding Buddies | Tech & Dev-Mindset / Clean Code #3 - (Funktion)iert das überhaupt?

Transcript

Clean Code #3 - (Funktion)iert das überhaupt? · Coding Buddies | Tech & Dev-Mindset

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