Latest / Coding Buddies | Tech & Dev-Mindset / Clean Code #4 - Immer diese Kommentare

Transcript

Clean Code #4 - Immer diese Kommentare · Coding Buddies | Tech & Dev-Mindset

0:00
Im aktuellen Projekt war wie reingeschaut, wieviel to dos wir
0:03
da drin haben und ich. Muss sagen super. 0.
0:09
Coating Boys Dein Podcast rund um Softwareentwicklung und
0:12
aktueller Technews herzlich willkommen.
0:19
Was? Einen wunderschönen guten Tag.
0:28
Herzlich Willkommen. Schön, dass du wieder
0:30
eingeschaltet hast. Zur neuen Folge deines
0:32
Lieblingspodcasts, was wir natürlich hoffen, der Coding
0:35
Buddies und zwar an meiner Seite natürlich wieder der
0:37
fantastische Fabi Moin Fabi. Morgen Kino genau und ich bin
0:42
auch dabei der Tino. Und ja fabi, ich hab Bock auf
0:48
diese Folge, aber erstmal möchte ich natürlich wissen, wie geht
0:52
es dir? Ja.
0:56
Bisschen müde irgendwie, würde ich sagen, aber sonst eigentlich
1:00
ganz gut. Okay also bist du bereit oder
1:03
oder wollen wir einfach jetzt hier abbrechen und dann andere
1:06
mal weitermachen oder oder sagst du so, ich bin zwar müde, aber
1:09
verdammt noch mal, lass uns diese Folge aufnehmen.
1:12
Ich bin müde, aber verdammt noch mal das kleine Schläfchen.
1:17
Denn ich habe ein geiles Thema mitgebracht.
1:19
Ich habe ein geiles Thema okay bis zur Wartung sind da.
1:23
Ja ich hoffe bei dir, liebe zuhören, liebe Zuhörer auch, und
1:27
zwar ist es heute mal wieder eine.
1:30
Cleancode Folge, Oh, das ist geil.
1:33
Kurz sacken lassen, kurz sagen, aber das geht halt mal wieder um
1:37
cleancode Nein, das ist ein Teil unserer cleancode Reihe
1:40
natürlich. Und zwar soll es heute um.
1:45
Wie sag ich es am besten, ohne gleich kritisch zu werden?
1:49
Um die Does und dont s in Sachen Kommentare innerhalb der
1:53
Programmierung gehen? OK, das ist das ist das relativ
1:57
neutral ausgedrückt, ja. Find ich gut.
2:00
Ja OK, dann lass uns das so machen, weil ich find das ist n
2:03
sehr spannendes Thema. Tatsächlich n Thema, was mich
2:08
selbst und dich glaub ich auch immer noch verfolgt und wirklich
2:10
auch verfolgt beziehungsweise heimsucht.
2:15
Weil das klingt immer alles so trivial in der Theorie, aber man
2:18
erwischt sich ja dann doch auch öfter mal auf der dont Seite.
2:24
Ja, und das würde ich gerne mal mit dir diskutieren.
2:26
Vielleicht hast du auch ein paar coole Beispiele oder was du da
2:28
so an Erfahrung gesammelt hast, dass wir das einfach mal so ein
2:31
bisschen beleuchten können. Ja, auf jeden Fall.
2:34
Bist du dabei oder steigst du jetzt an dieser Stelle aus?
2:38
Wann bin ich jemals hier ausgestiegen?
2:40
An. Dieser Stelle, das wird aber
2:41
durchgezogen. Deswegen würde ich sagen, lass
2:45
uns das ruhig mal so ein bisschen in Dose Don't
2:48
unterteilen und ich hoffe, dass wir auch ein paar Do s finden,
2:52
weil ich weiß ja von dir, dass du es sehr ähnlich handhabst wie
2:58
ich und wir gar nicht so die Fans von Kommentaren sind.
3:01
Das können wir auch mal erläutern, aber wer halt cool,
3:03
wenn wir vielleicht auch ein 2 Beispiele finden, auf der du
3:05
Seite ja klar. Aber lass uns das mal mit der
3:08
Linie dont Seite starten. Konzentrieren wir uns erstmal
3:12
auf die dont Seite. Ja, dann hau doch mal einen
3:14
Don't raus. Was ist so für dich n riesen
3:17
Punkt wo du sagst, bitte dafür keine Kommentare.
3:21
Da hatten wir letztens ja, da hatten wir letztens auch drüber
3:24
ganz kurz mal gesprochen und das möcht ich jetzt auch direkt
3:27
anbringen, weil ich da auch im Nachgang auf jeden Fall noch n
3:31
super Beispiel zu hab, was mir auch mal sag ich mal
3:34
untergekommen ist. Nicht von mir an der Stelle.
3:38
Sehr. Also ne Ausnahme natürlich.
3:43
Nein, aber. Zu dem Beispiel kommen wir
3:45
später. Und zwar geht es darum, dass man
3:47
zum Beispiel codeblöcke auskommentiert, also dass man
3:49
zum Beispiel sagt, Man hat n bestimmten Code, teil ne.
3:53
Und man kommentiert den Aus und sagt einfach.
3:57
Magst du kurz erklären, was das bedeutet?
3:59
Weil wir haben ja auch n paar Zuhörerinnen und Zuhörer, die
4:02
vielleicht noch am Anfang der Softwareentwicklung stehen und
4:05
vielleicht jetzt nicht so wirklich wissen, was du mit
4:07
Auskommentieren meinst. Also wenn du jetzt zum Beispiel
4:09
genau, also wenn du jetzt zum Beispiel sagst, du hast, sagen
4:13
wir mal, nimm ein einfaches Beispiel, du hast ein IF und ein
4:16
Else, also ein iffels Konstrukt. Und du sagst jetzt zum Beispiel
4:21
Ok, im Iffall möchte ich etwas Bestimmtes ausführen und im L 2
4:24
möchte ich etwas anderes bestimmtes ausführen.
4:27
Das heißt zum Beispiel, sagen wir mal, du möchtest.
4:33
Einen Zug regeln der soll eine bestimmte Geschwindigkeit haben
4:36
und wenn er jetzt ist, natürlich jetzt ein blödes Beispiel im
4:39
Sinne von ein sehr simples. Beispiel Mach weiter.
4:42
Aber im Sinne von Regelung bei Regelung ist natürlich sehr
4:44
komplex. Aber was ich meine ist
4:46
angenommen du hast jetzt zum Beispiel deine Geschwindigkeit
4:48
ist zu gering, dann möchtest du die sozusagen in einem
4:51
bestimmten Fall erhöhen. Ne, also keine Ahnung.
4:54
Du fährst kleiner 50 also im Iffall wenn du kleiner 50
4:59
fährst, dann betätige quasi das Gaspedal sozusagen im Zug
5:04
fiktiv. Ansonsten betätige bitte die
5:06
Bremse nur mal als ganz kleines Beispiel, was man sich
5:08
vielleicht jetzt so ganz schnell mal irgendwie vorstellen kann.
5:13
Und du sagst jetzt zum Beispiel, ah, na ich will es noch mal ganz
5:16
kurz was ausprobieren und ich packe jetzt zum Beispiel den
5:19
Else Fall weg, ne. Also Bremsen soll eigentlich gar
5:21
nicht stattfinden, du möchtest eigentlich nur in dem Fall nur
5:24
schneller werden, weil du willst irgendwas ausprobieren, bremsen
5:27
ist jetzt egal, keine Ahnung, so ist vielleicht eine Simulation.
5:31
Und dann bleibt das aber zum Beispiel auskommentiert, dass du
5:35
zum Beispiel einfach vergisst, das wieder Einzukommentieren
5:38
eine Möglichkeit, oder vielleicht hast du auch eine
5:41
andere Möglichkeit und zwar den Use Case, dass du vielleicht
5:43
sagst, du hast vielleicht noch mal ein anderes Beispiel, du
5:46
hast vielleicht einen Switch Case und sagst keine Ahnung.
5:50
In in in dem Fall zum Beispiel. Du hast jetzt irgendwie
5:53
bestimmte Personen, die irgendwo eintritt brauchen und keine
5:58
Ahnung, es geht um nen bestimmten Alterswert.
6:00
Du hast zum Beispiel Jugendliche, du hast Erwachsene,
6:03
du hast Rentner, was auch immer. Und anhand von dieser
6:07
Alterskategorie wird vielleicht irgendein Preis für den Eintritt
6:10
berechnet. Ne?
6:11
Ja. Und.
6:14
Aus welchen Gründen auch immer, wird zum Beispiel der Rabatt
6:18
für. Kinder oder Rentner mal
6:23
weggenommen, muss mal weggenommen werden und dann wird
6:25
das einfach auskommentiert und bleibt aber so im Code stehen.
6:30
OK, da würde ich aber gerne noch was zu ergänzen dazu, um das
6:34
gleich noch mal n bisschen zu erklären, was eigentlich
6:37
Auskommentieren an sich bedeutet.
6:40
Es geht ja allgemein in unserer Folge darum, Kommentare in den
6:44
Programmcode einzupflegen. Und Kommentare in dem Sinne,
6:48
dass zum Beispiel der Compiler oder der Interpreter diese
6:51
Zeilen ignoriert. Also das ist nicht Teil des
6:54
Programms ist. Und was du ja mit
6:56
Auskommentieren meinst. Und was denk ich mal vielen
6:59
klar, ist aber vielleicht nicht allen, deswegen möchte ich das
7:01
noch mal kurz erwähnen ist Kommentare sind, dass man quasi
7:04
diesen Programmcode, den du meinst innerhalb eines
7:09
Kommentars verpackt und dadurch quasi vom Interpreter oder vom
7:12
Compiler nicht mit berücksichtigt wird für das
7:15
Programm, weil es als Kommentar gilt und dadurch kann man quasi.
7:20
So n bisschen Bad Practice, sag ich mal.
7:23
Deswegen gehen wir darauf ein, Programmteile oder Codezeilen
7:28
ignorieren im Programm. So da, um das noch mal so
7:32
vielleicht für diejenigen, die nicht genau wissen, was das
7:34
bedeutet, das noch mal klarzustellen.
7:36
Also im Prinzip nimmt man nen Code teil und verpackt ihn als
7:40
Kommentar kurzzeitig, damit er einfach nicht Teil des Programms
7:43
ist. Und das ist ja so im Wortlaut
7:46
immer dieses ja kommentiert Mal den Code aus, weil ja jeder weiß
7:49
was zu tun ist. An der Stelle, aber was das
7:51
eigentlich bedeutet, dass da einfach nochmal kurz an der
7:53
Stelle erklärt und ja, du hast halt schon einen sehr geilen
7:57
Punkt gebracht, an der Stelle ist.
8:01
Wie verhält sich das Ganze? Ich kommentiere das aus, ja,
8:05
läuft ganz gut, machen wir erstmal weiter so und dann hast
8:08
du halt aus kommentierten Code, dann hast du halt diesen
8:10
Kommentar Blog in deinen Programmcode drin, der
8:14
eigentlich Code beinhaltet, der nicht mehr mitlaufen soll
8:17
sozusagen. Und das ist halt absolut Bad
8:20
Practice. Warum?
8:24
Die Frage ist oder sagen wir mal so was ist n Argument dafür das
8:28
zu tun? Ich kenne ein Argument was mir
8:31
sehr oft da begegnet ist ist na ja, vielleicht brauch ich den
8:34
Code noch. Ja ne, also vielleicht soll er
8:37
irgendwann wieder Teil meines Programms sein und deswegen er
8:40
ist erstmal nicht mehr aktiv Teil des Programms, aber ich
8:43
habe ihn noch, ich kann ihn jederzeit dieses sogenannte ein
8:46
Kommentieren, das heißt ich entferne einfach den
8:48
Kommentarblock da drum und dann ist es wieder Teil des Codes.
8:51
So, und da frag ich dich jetzt oder ich weiß, du wirst
8:54
wahrscheinlich mir das Ganze bestätigen, aber wieso sollte
8:57
ich das tun, gerade in Hinsicht dahin, dass ich ja sehr, sehr
9:02
wahrscheinlich heutzutage innerhalb eines Repositories
9:06
arbeite und quasi eine Versionsverwaltung habe?
9:09
Das heißt, dieser Programmteil, der ich also, den ich da aus
9:15
kommentiere, der ist ja versioniert, den kann ich ja
9:17
jederzeit wiederherstellen. Also angenommen du hast ihn
9:20
einmal committed. Ja, davon gehe ich jetzt mal.
9:23
Aus. Genau.
9:24
Aber sonst gehe ich da natürlich mit.
9:26
Das ist natürlich genau der Punkt was, was ich ganz
9:30
interessant finde bei der ganzen Sache ist und das passiert glaub
9:33
ich vielen zumindest mir auf jeden Fall ganz gerne, wenn man
9:37
jetzt zum Beispiel angenommen, du hast einen frischen Stand, es
9:39
wurde gerade irgendwas committed, du hast dir neu was
9:41
gepullt wie das Ganze mit Versionsverwaltung funktioniert,
9:45
da haben wir auch schon mal eine kleine Podcast folge drüber
9:47
gemacht, deswegen stelle ich das einfach mal aus, deswegen stelle
9:51
ich das jetzt einfach mal so hin, dass wir quasi auf diesem
9:54
Level reden. Und.
10:00
Wenn du jetzt zum Beispiel ne gerade frisch gepullt hast und
10:04
irgendwie n was einbauen möchtest und vielleicht du
10:08
programmierst was du sagst, OK, dann könnte vielleicht so n
10:10
Effekt, dass du etwas und sagst OK, jetzt kann ich das hier
10:13
vielleicht mal kurz wegnehmen, dann wird vielleicht irgendwie
10:15
dann ne kenn ich ganz gerne selber, dass man irgendwie
10:18
erstmal was auskommentiert anstatt wirklich den
10:21
Programmenteil, den man dort hat, einfach zu löschen.
10:25
Auch obwohl wir gerade noch, also wirklich gerade noch so
10:27
produktiv sind. Bevor wir einchecken, gucken wir
10:29
natürlich noch mal alles durch und entfernen dann diese
10:31
Kommentare. Angenommen man hat noch was
10:33
Auskommentiertes drin. Aber trotzdem erwische ich mich
10:39
manchmal, dass ich dann die Sachen nicht einfach weglösche,
10:40
sondern erstmal aus kommentieren.
10:42
Und das ist halt interessant, weil rein theoretisch, gerade
10:44
weil du es ja auch gesagt hattest.
10:46
Die Versionsverwaltung zeigte er an, Moment hier zum Beispiel ist
10:51
das hast du weggelöscht, das heißt, wenn man jetzt gucken
10:53
möchte, wie vielleicht dieser Code, den man irgendwie aus
10:55
kommentiert hat, aussah, weil man vielleicht an diese Logik
10:58
herankommen möchte, weil man vielleicht diese Logik noch mal
11:02
im Auge haben möchte oder irgendwie noch mal betrachten
11:04
möchte, dann kann man sie sich ja wieder angucken, einfach nur,
11:06
indem man sozusagen. Einen Diff macht zu dem was man
11:10
vorher hatte. Ne, das ist halt super spannend
11:13
weil ich kenn also dieses Verhalten kenn ich auch, ich
11:16
glaub das ist auch irgendwie noch so geschuldet aus
11:18
vergangenen Tagen wo man halt noch nicht so.
11:21
Vielleicht so routiniert war in der ganzen Versionsverwaltung
11:24
zum Beispiel mit Git zu arbeiten oder vielleicht wirklich in
11:28
kleineren Projekten gar kein Repository hatte und dann gesagt
11:31
hat, OKH nee, das will ich jetzt behalten, erstmal.
11:35
Aber wenn man ganz ehrlich ist, was er dafür spricht, den Code
11:39
einfach zu löschen, was also, was ist denn jetzt wesentlich
11:43
schneller den Code wieder mit einem Shortcut einzukommentieren
11:47
oder einfach n Reward schnell zu machen in der IDI, die dir das
11:50
ja anbietet um dir einfach kurz mal den Code wieder zu zeigen
11:53
oder wiederherzustellen? Also eigentlich ist es ja nicht
11:56
mal ein extremes Zeitersparnis zu sagen, ich kommentiere das
12:00
aus, weil dann kann ich es schneller wiederherstellen, also
12:02
moderne Ideas haben ja Song Support für Repositories, dass
12:06
du es ja einfach super schnell wiederherstellen kannst.
12:08
Alles ja genau. Aber wie gesagt, das sind halt
12:11
Sachen, die vielleicht durchaus mal auftreten können, aber ich
12:16
finde es ist halt auch immer die Sache so, gerade wenn du daran
12:19
arbeitest und Code aus kommentiert und vielleicht viel
12:22
Code aus kommentiert hast anstatt ihn zu löschen, wird es
12:25
halt auch irgendwann sehr sehr unübersichtlich und du verlierst
12:27
dich vielleicht in alten Gedanken, gerade wenn du etwas
12:30
neu machen möchtest. Aber wie gesagt, diese diese Art
12:35
und Weise Code Blöcke. Auszukommentieren es ist ja wie
12:38
gesagt, dass das ist jetzt ne Sache, wo wir an dem Punkt sind,
12:41
wo wir sagen, OK, vielleicht haben wir das noch nicht
12:43
kommentiert, vielleicht arbeiten wir gerade daran, kommentiert.
12:50
Vielleicht arbeiten wir gerade daran, aber was ich mal
12:53
anbringen möchte, ist das Beispiel, was ich vorhin genannt
12:56
hab, weil das find ich auch sehr spannend.
12:58
Ich hab mal an einem Projekt gearbeitet, ist schon n bisschen
13:00
länger her. Da gab es nen Code und es gab so
13:05
ne Art Tag an dem etwas vorgestellt wurde.
13:09
Ne und? Darf also jetzt neue Stände des
13:14
der Software oder was meinst ja mehr oder weniger genau.
13:17
Also du hast quasi Software geschrieben und es wurde quasi
13:21
diese Software wurde sozusagen vorgestellt, ne.
13:25
Jetzt nicht direkt die Software, sondern das was die Software
13:28
tut. Und dann?
13:33
Keine Ahnung, dieser vorstellungstag, sag ich jetzt
13:36
mal, war vorbei. Es gab einen bestimmten Commit
13:39
und ich habe an der Software weitergearbeitet.
13:42
Und ich war nicht der Einzige, der an dieser Software
13:44
gearbeitet hat und hab dann geguckt, OK, irgendwie lief was
13:50
nicht, was ich mir was eigentlich hätte laufen sollen,
13:54
meiner Meinung nach und. Dazu muss man sagen, es gab
13:58
keine Tests an dieser Stelle. Ja, nicht schön.
14:05
Würde ich auf jeden Fall auch vermeiden.
14:07
Zu haben und was ich super interessant fand war.
14:12
Dass ich irgendwann bei der Recherche, wieso das nicht
14:14
funktioniert hat, wo ich der Meinung war, dass es hätte
14:17
funktionieren müssen. Hab ich geguckt und da stand.
14:22
Es war ein Codeblock auskommentiert, der war
14:24
eingecheckt, so auskommentiert wie er, ne wie er da drin war
14:28
und da drüber stand. Ich sag mal sinngemäß.
14:33
Auskommentiert wegen diesem Vorstellungstag.
14:37
So also quasi hat sich jemand gesagt, OK, warte mal, es gibt
14:43
jetzt vielleicht n bestimmten Fall dieser Codeblock den wir da
14:46
haben, den brauchen wir jetzt nicht für diesen
14:49
Vorstellungstag, also quasi wieso ne Art vielleicht, ich sag
14:53
mal vielleicht eine Art Workaround vielleicht.
14:57
Irgendwas, was vielleicht, wo gerade gerade dran gearbeitet
15:00
wurde oder vielleicht auch ein neues Feature oder sowas,
15:02
vielleicht neues Feature, vielleicht irgendwas.
15:04
Ich weiß es auch nicht mehr genau, ich weiß jedenfalls nur
15:06
noch, dass quasi eine bestimmte Sache entfernt wurde, aber noch
15:11
im Code war und mit dem Kommentar wegen diesem
15:14
Vorstellungstag nenne ich es jetzt mal.
15:17
Bis das jetzt auskommentiert worden wurde, danach aber auch
15:20
nicht wieder ein kommentiert und da sieht man eigentlich schon
15:22
mal, dass es halt ist. Also das war halt wirklich ein
15:24
absoluter, wie sagt man Paint. Weil du halt wirklich mehr oder
15:32
weniger an dieser Stelle wurde, diese Software, ich sag mal
15:36
kaputt gemacht ne und nicht wieder repariert und das war
15:40
schon echt ein bisschen krass. Also das war für mich n
15:43
Beispiel, wo ich mir dachte, OK auskommentierter Code
15:45
eingecheckt mit einem Kommentar, der heißt OK, das hab ich
15:50
auskommentiert nur für diesen einen Use Case sozusagen
15:53
temporär, was nicht wieder einkommentiert wurde das das war
15:56
auf jeden Fall. In diesem Punkt.
15:58
Glaub ich das krasseste was ich je gesehen hab.
16:01
Ja, also man muss natürlich fairerweise sagen, dass
16:05
zumindestens der Wille da war ranzuschreiben warum das Ganze
16:09
passiert ist, weil noch schlimmer wär ja, wenn das
16:11
einfach, also dann hätte es ja nicht mal n Anhaltspunkt warum
16:13
da jetzt auskommentierter Code ist.
16:15
Ne, aber um das Ganze diesen Punkt auch mal abzurunden
16:20
würdest du sagen das Don't an der Stelle ist ja nicht mal
16:23
unbedingt auf der Arbeitsbasis, also während ich daran arbeite
16:28
Sachen Auszukommentieren vielleicht um kurz mal was zu
16:30
testen sondern. Don't dahinter ist ja eigentlich
16:33
aus kommentierten Code einzuchecken.
16:36
Am Ende also zu sagen, das ist jetzt mein Stand, auf dem weiter
16:40
gearbeitet wird und da sind auskommentierte Code Elemente
16:43
drin. Genau.
16:44
Also ich würde sowas zum Beispiel vermeiden, indem ich
16:47
bevor ich etwas committe mir alle changes die ich gemacht
16:52
habe noch mal durchgucke. Also noch mal n Review machst.
16:55
N Review machen und wenn es nun kurzes Review ist, um einmal zu
16:59
gucken, OK, habe ich jetzt irgendwie.
17:03
Grobe Patzer drin, ne, also angenommen weil wir haben ja
17:07
schon öfter mal gesagt, dass wir auch zum Beispiel gerne ein Pair
17:09
programming arbeiten, da muss man nicht ein so intensives Code
17:12
Review machen am Ende als wenn man jetzt zum Beispiel alleine
17:15
Code bearbeitet und dann vielleicht noch mal mit wem
17:17
anders das Reviewed aber Fakt ist auf jeden Fall, gerade in
17:20
solchen Punkten, wo du schon sehr viel Code zusammen
17:23
betrachtet hast, ist es immerhin noch mal interessant zu sagen
17:26
okay habe ich noch irgendwelche Konsolenausgaben drin, die
17:29
eigentlich nicht sein sollten oder habe ich irgendwie zum
17:31
Beispiel aus kommentierten Code an der Stelle, das würde ich so
17:34
würde ich versuchen dem entgegenzuwirken, auf jeden Fall
17:37
aber. Man ja auch ehrlicherweise
17:38
sagen, wenn wir jetzt zum Beispiel im Pair arbeiten und
17:41
danach so n Review noch machen. Ist ja nicht so, als wenn das
17:46
nur so. Prozesshalber ist, sondern wir
17:49
finden ja trotzdem Sachen ne, weil du meinst, das kann ja
17:52
kürzer sein, das stimmt, aber ich find es trotzdem gut und es
17:55
hat sich schon oft bewährt, dass wir es trotzdem machen und nicht
17:58
sagen, so ey. Na komm, wir gucken die ganze
17:59
Zeit zusammen drauf, dass es safe das Ding ja genau weil
18:02
genau so ne Sache wie du meinst, so Konsolenausgaben oder
18:04
vielleicht dann doch noch mal was aus Kommentiertes wo du
18:06
denkst, hey, das brauchen wir gar nicht mehr so nach dem
18:09
Motto, Weil es halt irgendwas neues war bleibt es drin, bleibt
18:12
es nicht drin, weißt du wie es halt so ist.
18:16
Und da finde ich halt, das Review ist dann immer super
18:20
hilfreich. Okay fand ich auf jeden Fall ein
18:23
sehr starker erster Punkt ist auch einer der Keypoints in
18:27
meinen Augen, wo man Kommentare halt blöd gesagt missbrauchen
18:31
kann für. Hau mal nächsten raus.
18:37
Was noch ein Punkt ist. Ja, den können wir vielleicht
18:42
relativ schneller mal so, jetzt mal n bisschen schneller
18:44
abhandeln. Ist natürlich.
18:47
Kommentare dafür zu nutzen, den Code zu erklären, das heißt ich
18:52
schreib ne Funktion und hab dann innerhalb dieser Funktion zum
18:57
Beispiel ein paar Zeilen Kommentare.
19:01
Jetzt passiert das und das oder falls.
19:05
Mal Eintritt, führe das und das aus, mal so vereinfacht gesagt
19:09
und bewusst habe ich jetzt schon sowas gesagt wie Falz das und
19:13
das ist, weil das klingt ja jetzt schon ganz stark nach
19:15
einer If Bedingung. Das ist nämlich genau mein
19:20
Klemma, die ich damit hab und deswegen ist das für mich jetzt
19:22
auch n dont den sagen wir mal 90% der Fälle.
19:26
Wir können ja auch mal vielleicht die anderen 10% dazu
19:28
noch mal ansprechen, aber es ist n Hinweis darauf, dass man
19:33
vielleicht nicht ganz so sauber gecodet hat, wenn es wirklich
19:37
wirklich notwendig ist, Kommentare ranzumachen, die
19:40
erklären was innerhalb dieser Funktion passiert und da hatte
19:44
ich, das hatte ich glaube ich auch schon mal im Podcast
19:46
erzählt, dass ich mal ein Projekt hatte, wo der
19:48
Projektleiter sehr stark darauf bestanden hat, dass Code
19:51
kommentiert werden musste, weil der Prozess das wahrscheinlich
19:54
irgendwie verlangt hat. Also ich weiß nicht, was ihn da
19:57
getriggert hat oder getrieben hat.
20:00
Aber das war eine Belastung und keine Hilfe, weil du denkst, du
20:04
so, warum muss ich denn jetzt diese eine Zeile kommentieren?
20:08
Also da steht doch da was, da passiert was für mich wieder ein
20:12
Zeichen war, dass ich es ja eigentlich ganz geil gecoded
20:14
habe, weil es gab keinen Klärungsbedarf an der Stelle und
20:18
trotzdem sollten der Kommentar rein und das ist halt für mich
20:20
ein absolutes Notebook. Und ein dont auf der Seite.
20:23
Ich würde das Ganze vielleicht unter redundante Kommentare
20:27
vielleicht mal benennen, weil im Endeffekt geht es ja darum, dass
20:30
du sozusagen mit Kommentaren redundant erklärst, was
20:35
eigentlich der Code im optimalen Fall selbsterklärend.
20:40
Zeigen soll. Ja, das ist ein guter Punkt,
20:43
finde ich gut. Ja, was ich halt.
20:45
Was auf jeden Fall auch noch ein Punkt ist, also was darüber noch
20:48
hinausgeht, ist ja, dass wenn du dir überlegst, okay im
20:51
Normalfall das kennt, glaube ich kennen viele, ist ja Code, ist
20:57
ja sehr lebendig, nenne ich das jetzt mal.
20:59
Also er verändert sich häufig und angenommen du hast zum
21:04
Beispiel die Anforderungen, warum auch immer, dass dir
21:07
jemand sagt, KOMMENTIERE bitte jede Zeile Code.
21:11
Was für einen unglaublichen Overhead generiert man, wenn man
21:14
sozusagen sagt, ich verändere jetzt den Code?
21:19
Weil jede Zeile, die du änderst, musst du nicht nur umschreiben,
21:22
sondern du musst auch noch zusätzlich den Kommentar
21:24
verändern. Und das ist halt genau das da.
21:27
Da kommt ja beim Refactoring kommt das zum Beispiel dazu, ne,
21:30
wenn du jetzt wirklich, das musst du ja auch echt auf jeden
21:32
Fall an die Kommentare denken. Genau, und da hat keiner Lust
21:35
drauf. Da hat gar keiner wacht, auf
21:37
keinen Sinn. Genau dann hast du nachher den
21:41
worst case, dass du Kommentare hast, die gar nicht mehr zu dem
21:43
Code passen. Das heißt, sie sind nicht nur
21:45
überflüssig, sondern auch noch falsch.
21:47
Genau, ja, das ist n cooler Punkt auf jeden Fall.
21:53
Absolutes Dont in meinen Augen. Gibt es Fälle, wo du dir
21:57
vorstellen kannst, dass es denn so Richtung du wandert, um da
22:00
mal was zu benennen? Ja, also schon.
22:04
Also es kann halt durchaus sein, dass du vielleicht irgendwie,
22:07
sagen wir mal domainspezifische Informationen vielleicht
22:10
mitgeben musst. Also angenommen, du hast zum
22:13
Beispiel eine bestimmte Berechnung, die in einem ganz
22:16
bestimmten Sektor stattfindet, zum Beispiel, sagen wir mal, in
22:20
einem Finanzbereich oder in irgendeiner Physik Engine, um
22:25
mal 2 komplett verschiedene Bereiche zu benennen, wo du
22:28
vielleicht bestimmte Konstanten hast, die dir eventuell.
22:34
Also die vielen Leuten vielleicht unbekannt sind.
22:37
Weißt du, dass du sagst okay, warum wird jetzt vielleicht
22:40
genau etwas? Rechnet.
22:42
Warum wird diese Berechnung an dieser Stelle angestellt?
22:46
Dann ist es vielleicht durchaus hilfreich, Kommentare für eine
22:50
sage ich mal, Anreicherung von Informationen, die halt eben
22:54
genau in dieser Domainspezifisch sind, dem.
22:57
Nachfolger oder der Nachfolgerin in diesem Code teil eben zu
23:00
helfen, ne also Hinweise zu geben um eben ein besseres
23:04
Verständnis zu generieren, was theoretisch nicht einfach
23:08
ersichtlich ist. Also gerade wenn jetzt ich ich
23:11
versuch mal. Beispiel zu generieren.
23:13
Gerade wenn du sagst. Vielleicht weiß zum Beispiel.
23:19
Vielleicht wissen viele, wie man zum Beispiel keine Ahnung eine.
23:23
Berechnung von einer Geschwindigkeit, Beschleunigung
23:26
auf keine Ahnung der Erde berechnet und wenn man es nicht
23:30
weiß, kann man relativ schnell nachgucken, ob diese Berechnung
23:33
tatsächlich richtig angestellt wurde.
23:34
Im Code ist vielleicht nicht unbedingt kommentierungswürdig
23:38
würde ich sagen, ne wenn es jetzt zum Beispiel um eine
23:40
Funktion geht, die eine Beschleunigung berechnet, aber
23:42
angenommen du hast sagen wir mal ein Spiel.
23:46
Wo du auf eine Beschleunigung für einen keine Ahnung ganz
23:50
bestimmten Bereich, der vielleicht verzaubert ist und
23:53
irgendwas Spezielles darauf einfällt.
23:57
Vielleicht speziell darauf einwirkt.
23:58
Weißt du, dass sich zum Beispiel jemand hinstellt und sagt Häää
24:01
Beschleunigung, was ist das für ein Quatsch, das stimmt doch
24:03
vorne und hinten nicht, weil halt eben die Berechnung
24:06
deutlich abweicht von dem, wie man es vielleicht ursprünglich
24:10
kennt, aber du halte dich in einem ganz bestimmten Bereich,
24:13
Aufhältst an dieser Stelle des Codes, der Halt eben genau einem
24:18
mögliche einen möglichen Fehler, den man vielleicht erkennen
24:23
könnte, eigentlich wirklich aber so gewonnen.
24:27
Wie es ist. Und da könnte vielleicht dann
24:29
zum Beispiel ein Kommentar helfen zu sagen, OK, an dieser
24:31
Stelle wird es wirklich so gemacht, weil ne unter
24:34
bestimmten, also wegen besagtem. Nerv erwähnen besagtem ja.
24:39
Ja find ich, ist n auf jeden Fall n guter Punkt, wenn halt
24:42
zum Beispiel so Konstanten einfach nicht so gängig sind.
24:45
Beispielsweise find ich auf jeden Fall sehr cool, wo mir das
24:49
auch. Oft begegnet ist, und das ist so
24:51
n bisschen, da bin ich n bisschen, ja, ich sag mal hin
24:55
und hergerissen war damals in dem Embedded Projekt.
25:01
Dass man ja quasi auf der Hardware.
25:06
Quasi die Register beschreibt, das heißt, an gewissen
25:09
speicheradressen Werte setzt, um dann die Register, quasi die
25:14
einzelnen Bits zu aktivieren, um so Konfigurationen herzustellen,
25:17
um mal das Mal ganz kurz zu erklären.
25:19
So ne, also du schreibst zum Beispiel eine 1 rein, dann ist
25:22
das erste Bit gesetzt und dadurch wird halt die Hardware
25:25
umkonfiguriert. Hat denn zum Beispiel eine
25:27
Funktionalität an oder aus, so kann man sich das vorstellen und
25:31
so bit. Region.
25:34
Um zum Beispiel gezielt Bits anzumachen, um Masken dabei zu
25:39
verwenden, um Shift Operation, was es denn halt alles so gibt,
25:42
was man da denn verwendet, will ich jetzt nicht zu detailliert
25:45
eingehen, aber vielleicht merkt man schon, das ist vielleicht
25:48
auf den ersten Blick dann gar nicht mehr so trivial zu
25:51
erkennen, was da passiert und warum man das macht.
25:55
Da kann man Kommentare verwenden.
26:00
Ja, ich bringe mal irgendein Beispiel.
26:02
Sowas wie ja, aktiviere mal den watchdog jetzt da drauf, dass du
26:06
so eine gewisse Überwachungsfunktion auf der
26:07
Hardware anschaltet. Dafür musst du im Register a das
26:12
vierte Bit ansetzen und um gewissen Modus davon noch zu
26:15
machen, muss auch noch das zweite Bild an sein.
26:18
So das heißt du Shift ist entweder die Zahlen da rein oder
26:21
setzt mit einer Maske dann die Werte da drin.
26:23
Wie auch immer, du hast halt eine Funktion die das Macht
26:26
valide zu sagen ich mach mal einen Kommentar an sowas wie
26:30
enable watchdog. Irgendwas, so eine Möglichkeit
26:35
würde ich sagen, ist OK, weil man ja aus dem Kopf nicht
26:38
unbedingt weiß, wie man das einstellt auf der Hardware, da
26:43
ja valider Punkt besser wäre, aber noch, weil wir auch diese
26:48
Funktionsfolge schon dazu gemacht haben, ist diesen Code
26:50
einfach noch mal in der Funktion auszulagern, die heißt Enable
26:54
watchdog und dann vielleicht noch setmode und dann kannst du
26:58
es eigentlich schon wieder schaffen, dass der Code sich
27:00
selbst erklärt, also kann man es schon wieder.
27:02
Dieses Argument so ein bisschen aushebeln, aber das ist trotzdem
27:05
ein Punkt wo ich sage ist ok. Da n Kommentar ranmachst aber
27:08
wär vielleicht schöner, wenn du das noch so mit den Funktionen
27:10
beschreiben könntest. Ja, ich verstehe worauf du
27:14
hinaus willst. Es ist ja vielleicht doch
27:17
interessant, an der Stelle selbst wenn du zum Beispiel
27:20
sagst Enable Watch Dog, ist es ja vielleicht.
27:22
Also selbst wenn du ne Funktion erstellst, könnte man ja
27:25
vielleicht trotzdem noch dazu schreiben.
27:26
OK, es ist das vierte Bit, ne, weil es könnte ja auch zum
27:29
Beispiel sein, dass jemand angenommen, keine Ahnung.
27:33
Sich sagt Okay welches ist es denn jetzt?
27:35
Das ist das wohl das Dritte. Obwohl es das Vierte ist.
27:39
Und da ist vielleicht ein Fehler drin oder was auch immer.
27:41
Ne also. Aber so könntest du es
27:44
zumindestens Kapseln, dass quasi Leute, die von außen drauf
27:47
gucken sich denken, OK der watchdog wird enabled ja so ja
27:51
beispielsweise genau genau. Ja, was haben wir noch so für
27:57
Punkte? Ich hatte noch einen, lass mich
27:59
kurz überlegen, ja kurz überlegen, ich könnte.
28:02
Vielleicht. Wenn.
28:04
Es jetzt eigentlich ja, ja, mir ist das eingefallen, bevor sie
28:06
da weg ist, hatten wir auch schon mal thematisiert, und zwar
28:11
to do. Kommentare ist auch ein sehr
28:13
spannender Bereich. Sehr schön wollte.
28:15
Ich auch gerade anbringen, das gibt's ja nicht.
28:17
Ja, dann ist ja gut, dann lass doch darüber reden.
28:21
Kurze Erklärung dazu für diejenigen, die es nicht wissen.
28:23
To do Kommentare sind oftmals dafür verwendet, wie es schon
28:27
heißt, to do, also wie eine aufgabenliste, dass man sagt
28:30
Okay hier an dem Code, da passt was nicht oder da fehlt
28:33
vielleicht noch Funktionalität, kann ich jetzt aus gründen, ich
28:38
weiß man also es ist immer schwer zu sagen was ist ein
28:40
valider Grund das jetzt nichts zu tun, das hatten wir auch
28:42
schon mal thematisiert. Aber dass man sagt, ich kann es
28:46
jetzt nicht tun, ich mache mir einen Kommentar an schreibe.
28:50
To do und dann was noch zu tun ist und tatsächlich, viele IDES
28:56
unterstützen das ja schon seit langem, dass es ne Art
28:58
highlighting gibt dafür, dass du zum Beispiel sagen kannst, wenn
29:01
ich jetzt to do als Keyword davor schreibe, wird mir das
29:04
farblich markiert. Der Kommentar, dass es sich
29:06
abhebt, ich kann denn im ganzen Projekt super schnell nach to do
29:10
s suchen, kann mir Aufgabenlisten erstellen, das
29:12
wird ja alles unterstützt. Ja, feine Sache.
29:16
Ist denn das Problem bei to dos noch mal kurz zusammengefasst?
29:20
Ja, also ich, ich würd es n bisschen aufteilen, weil
29:25
prinzipiell bin ich auch kein Fender von to do s
29:27
ranzuschreiben. Und gleichzeitig muss man sagen,
29:31
passiert es einem, dann ist auch wieder die Frage OK, ist es denn
29:36
wirklich absolut schlimm und n absolutes No go to dos
29:39
ranzuschreiben. Ich weiß nicht, ich würde sagen,
29:43
es ist jetzt nicht unbedingt n absolutes No go zu sagen, OK,
29:47
ich schreibe ein to do dran, ich glaube das Problem bei Todo s
29:52
entsteht darin. Wenn zum Beispiel to do
29:57
Kommentare nicht aktiv verwaltet werden und das hab ich zum
30:00
Beispiel auch schon sehr, sehr oft mitgekriegt, dass du zum
30:03
Beispiel. To dos dran schreibst oder
30:07
jemand anders hat n to do dran geschrieben und entweder du
30:10
entdeckst deinen eigenen to do Kommentar oder von jemand
30:13
anderem und. So OK.
30:17
Also ja stimmt, müsste man mal machen.
30:22
Von wann ist der von vor 2 Monaten wurde also seit 2
30:26
Monaten nicht gemacht. Und dann ist die Frage OK, macht
30:30
man es jetzt oder vielleicht guckt man sich es wieder in 2
30:33
Monaten an. Das ist halt immer die Frage und
30:35
dann ist auch gleichzeitig wieder die Frage, wenn etwas 2
30:38
Monate als to do drin steht, wie wichtig war dann dieser Todo?
30:43
War dieser Punkt. Also das ist halt genauso dieser
30:46
Trade off, weil im Endeffekt würde ich sagen, sind to do
30:49
Kommentare okay möglich und nicht absolutes No go Logo
30:55
entsteht darin, wenn man einfach nur to do Kommentare dran
30:58
schreiben, die aber nie macht und nie umsetzt.
31:01
Ja. So würd ich.
31:06
Ja, also ich find das Thema ist echt schwierig, weil wie du
31:09
schon meintest, du erwischt dich selbst dabei.
31:13
Ich erwisch dich auch sehr oft dabei.
31:16
Nee, aber das ist wirklich n Punkt, wo ich auch selbst super
31:20
mit struggle, dass ich da wirklich ein Thema mit hab, weil
31:23
ich weiß, es ist nicht cool. Ich kenne mich selbst.
31:26
Ich weiß genau was du meinst. Dann sind die 2 Monate alt und
31:30
wie wahrscheinlich ist denn bitte noch, dass das umgesetzt
31:33
wird? Also es ist ja wesentlich
31:35
wahrscheinlicher, dass diese Liste gefüllt wird und nie
31:38
abgearbeitet wird, dass du dann immer diese Kommentare hast.
31:41
Dann kommst du irgendwann an diesem Codeteil vorbei, liest
31:44
den Kommentar. Ah ja, ja, Ach ja, verdammt
31:49
anderen. Und ich hab mir mal den Spaß
31:52
gemacht und hab in unserem aktuellen Projekt war wie
31:55
reingeschaut. Wieviel to do s wir da drin
31:57
haben und super. 0. Der Hammer.
32:06
Nein, also ich hab es schlimmer erwartet, aber ich wusste
32:09
natürlich, dass es welche gibt, weil wie ich gerade schon
32:11
meinte. Man kommt ja ab und zu mal dran
32:14
vorbei und liest sie dann. Tatsächlich sind es 8 Stück, nur
32:19
das geht und ich finde das geht, das ist in Ordnung und das auf
32:22
20 Zeilen Code ist okay ich meine immerhin haben wir jetzt
32:26
schon 3 Funktionen geschrieben. Nee, aber da war Chapeau an uns,
32:33
aber gleichzeitig auch nochmal die Mahnung jetzt hier.
32:36
Alle haben es jetzt gehört, wir müssen aber noch mal ein
32:39
bisschen dran arbeiten. Ein guter Punkt.
32:45
Das ist halt wirklich und ich glaub liebe zuhören lieber
32:47
Zuhörer, falls dir das so ähnlich geht, dann lass dir
32:50
gesagt sein, du bist nicht allein damit die, also es ist
32:54
sehr verführend to do's zu verwenden, weil was es mir in
32:58
dem Moment gibt und deswegen ist es glaube ich der Grund warum
33:01
ich es öfter mal verwende ist einfach es nimmt in dem Moment
33:05
dir den Druck. Sich darum kümmern zu müssen,
33:08
weil du hast das Gefühl, es ist abgehakt, also so.
33:12
Ja ich hab n Toodura angeschrieben, es ist
33:15
berücksichtigt, es wird noch gemacht, ich bin erstmal fein
33:18
damit. Obwohl vielleicht im Hinterkopf
33:20
schon irgendwo sitzt, so nach dem Motto, Es wird niemals
33:22
passieren, niemals weißt du. Aber in dem Moment denkst du dir
33:27
erstmal OK, grüner Haken dran ist n to do Kommentar da die
33:31
Frage, das ist eigentlich ne uncoole Sache.
33:33
Die Frage an der Stelle ist ja OK, angenommen du sagst ey ich
33:36
bin jetzt an einem Punkt im Code, ich sehe etwas was zu tun
33:40
ist. Und jetzt hab ich im Hinterkopf,
33:44
ich soll kein to do ran schreiben.
33:46
Was tu ich dann? Also nach der Theorie im Best
33:52
Case oder was Real. Passiert in der Theorie im Best
33:56
Case. Was würde man denn?
33:57
Naja, das hatten wir mit der Later Equity Never Folge kümmer
34:02
dich sofort drum, sonst wird es nicht passieren.
34:04
Genau. Aber die.
34:07
Ist ja wahrscheinlich n bisschen ne andere.
34:09
Also ich kenn es zum Beispiel, was ich auch aus meiner sag ich
34:13
mal Erfahrung her sagen kann, was an sich ganz gut
34:18
funktioniert hat, war der Punkt, dass man auf to do Kommentare
34:22
verzichtet hat und dann zum Beispiel.
34:26
Sich ein, ich sag mal, wenn man ein schönes Ticket System hat
34:31
für das Team ein Ticket beziehungsweise ein Shore
34:35
anlegt. Das hieß bei uns damals Tor,
34:36
also quasi eine keine keine User Story die User Mehrwert bringt
34:41
in dem Sinne, sondern sozusagen kein User Value liefert, aber.
34:47
Sozusagen den Code verbessert eventuell.
34:51
Das könnte ein to do sein, dass man sagt, hier ich muss noch mal
34:54
das und das noch mal umbauen oder was auch immer oder
34:57
vielleicht noch mal vielleicht irgendwie in möglichen
35:01
Fehlerfall abfangen, was man vielleicht gar nicht als User
35:03
mitkriegt, aber sozusagen den Coachuner macht.
35:05
Es lief dann unter Chors. Und die haben wir dann angelegt
35:09
im Team. Und haben die dann sozusagen
35:14
auch versucht, zeitnah zu bearbeiten?
35:16
Ne, hier wieder der Fokus auf oder man betone versucht hat
35:22
nicht immer funktioniert, aber es war auf jeden Fall so, dass
35:24
quasi keine To do Kommentare im Code standen, die einen
35:27
irgendwie so nach dem Motto Jetzt muss man, das müsste man
35:31
ja auch noch machen ja stimmt. Aber es war immer sowas, wenn
35:35
man mal Zeit hatte, konnte man sozusagen in die Chorkiste
35:39
greifen und da was abarbeiten das.
35:43
Ja, das ist sehr spannend. Das heißt, Ihr habt euch das
35:47
dann selbständig aus dieser short Kiste, wie du es gerade so
35:50
schön genannt hast, gezogen oder wurde das jetzt?
35:53
Es war ja auch im agilen Umfeld, soweit ich das jetzt Änderungen
35:56
hab oder wurde das aktiv mit eingeplant, zum Beispiel im
36:00
nächsten Sprint in der nächsten Iteration Nene, also das
36:03
manchmal schon manchmal nicht, es war immer so, das wäre ja an
36:06
sich ein super cooler Umgang damit ja also es war ein
36:09
bisschen on demand, also es gab schon Punkte die tatsächlich mit
36:14
eingeplant wurden. Es gab aber auch andere Punkte,
36:17
die einfach so ein bisschen als Art.
36:22
Backlog da waren gedient haben, sagt man das so?
36:28
Wo man also, bei dem man sich dann halt einfach bedienen
36:31
konnte. Angenommen, man hat zum
36:33
Beispiel. Kam auch vor mal keine neuen
36:38
User Stories gehabt. Ja, selten, oder?
36:44
Tatsächlich war das nicht immer selten.
36:46
Also es kam durchaus ab und an vor.
36:49
Und dann hat das ganz gut funktioniert.
36:51
Ja, dann ist so ne Grabbelkiste natürlich nicht schlecht, ne,
36:54
also wo du noch mal sagen kannst genau, ich hab gar keine Lust
36:57
reinzugreifen mich darum zu kümmern, aber es muss ja jetzt
36:59
passieren. Aber es setzt natürlich voraus,
37:02
dass man irgendwie ne gewisse Velocity hat, die das zulässt
37:06
und auch. Also du hast nen input, du hast
37:09
nen Output und wenn aber der Input generell größer ist als
37:12
der Output, was ja durchaus vorkommen kann, dann ist es
37:15
natürlich nicht unbedingt hilfreich, dann sollte man es
37:19
mit einplanen, wahrscheinlich. Aber das war eine übliche
37:23
Herangehensweise, um to do s sozusagen.
37:27
Zu umgehen. Also muss ich sagen, gefällt mir
37:31
sehr gut, habe ich so noch nicht gelebt, könnten wir ja für uns,
37:35
für unsere 8 to lose auch mal in Erwägung ziehen, weil es dann
37:40
halt einfach die Wahrscheinlichkeit wieder
37:42
drastisch erhöht, dass es umgesetzt wird, es sei denn, du
37:45
hast natürlich wieder ein total zugemülltes Backblock mit
37:47
Tausende Tickets und findest da denn nicht mehr, aber du hast ja
37:51
als Prämisse gesetzt, dass man ein gutes System dahinter hat,
37:54
was aufgeräumt ist. Sehr, sehr cooler Punkt.
37:58
Fabi hat mir den fand ich wirklich cool, danke, dass du es
38:01
mit mir und den Zuhörern geteilt hast.
38:04
Du, ich würde es sagen, einen letzten hätt ich noch OK.
38:08
Dann hau mal raus. Vielleicht hab ich auch noch
38:10
einen kurzen aber. Weil das ist eine Sache, da habe
38:14
ich auch so meine Erfahrungen mitgemacht.
38:18
Und zwar geht es darum, wie erkläre ich das, dass du eine
38:23
gewisse Art von Dokumentation und Information.
38:29
Den den Code über Kommentare, Verpackst und die aber gewollt
38:35
sind und vor allem langfristig sind.
38:39
Ich bring mal n Beispiel, es gibt 2 verschiedene Beispiele,
38:44
bring ich mal die mir da sehr oft begegnet sind und die ich
38:46
irgendwie nie cool fand. Das eine sind so was wie.
38:55
Changelogs in Files ich weiß nicht ob du sowas kennst.
38:59
Ja. Wenn wenn du zum Beispiel dann
39:02
oben ne Art Header hast, wo dann drin steht, wer war der Autor,
39:07
wer war der letzte, der es geändert hat und dann halt auch
39:10
so eine Art Versionierung im Kommentar.
39:14
Dass es eine Version gibt und drin steht.
39:18
Wer was geändert hat? Und.
39:20
Wann? Mag sein, dass da gewisse
39:25
Automatisierungstools dahinter stecken, Stichwort automatische
39:29
Code, Generierung wie Doxygen mal so als toolbeispiel, dass du
39:33
halt verschiedene Dokumentationen dann aus dem
39:37
Code generieren kannst, hat seine Daseinsberechtigung, aber
39:41
ich stehe manchmal echt ein bisschen auf Kriegsfuß damit,
39:43
weil es kann also was einem klar sein muss und deswegen möchte
39:49
ich diesen Punkt ansprechen ist dass diese Information.
39:53
Echt super schwer sind aktuell zu halten, weil das hatten wir
39:57
vorhin ja auch schon bei den Kommentaren innerhalb der
39:59
Funktion, an der du aber aktiv arbeitest.
40:03
Und jetzt stell dir vor, du musst jetzt noch so ein
40:04
Changelog oben in jedem Fall was du geändert hast pflegen ja das
40:08
weil das irgendwie Anforderungen im Projekt ist, dass du rein
40:11
schreibst. Wir haben keine Ahnung den 2512
40:17
und Tino hat jetzt in dieser Funktion die Funktion sowieso
40:20
geändert, weil die Berechnung falsch war oder so.
40:24
Ich frage mich halt immer, an welcher Stelle sowas dann
40:26
wirklich wertvoll ist, weil du hast dafür ja auch, wie wir es
40:30
schon angesprochen haben, eine Sanierung ganz genau.
40:34
Du hast ja einen Commit, der dahinter steht.
40:36
Commit Messages ist auch so ein Thema, kann man auch mal eine
40:39
Folge drüber machen, aber hoffentlich wird ja die Commit
40:43
Message aussagekräftig genug sein um schon zu erklären was da
40:47
passiert ist und dem Vorteil den du dabei hast.
40:49
Du hast es noch commitübergreifend, also nicht
40:51
commitübergreifend, sondern. In dem in dem Scope deines
40:55
Commits, das heißt, Wenn du mehrere Files angerührt hast,
40:58
siehst du gleich, was sich alles bezüglich Deines Commits
41:00
geändert hat und nicht nur in diesem einen File.
41:06
Du bist verpflichtet, dass er automatisch aktuell zu halten,
41:09
in dem Moment, wenn du was eincheckst und committest jetzt
41:11
bei Git beispielsweise musst du ja einen Kommentar anschreiben
41:14
oder solltest du, also du wirst auf jeden Fall aktiv darauf
41:17
hingewiesen und so ein Header in File spätestens bei der 2.3.
41:22
Änderung wirst du vergessen, ist meine Meinung dazu.
41:26
Genau das war das eine Beispiel und ganz kurz das andere.
41:28
Noch, weil das in die ähnliche Richtung geht, weil ich jetzt
41:31
Dogs schon angesprochen habe ist, dass du so eine Art Header.
41:36
Kommentare machst gerade in der C Welt hatten wir das auch viel
41:41
gemacht, also in verschiedenen Projekten.
41:43
Ich hatte ja so mehrere Embedded Projekte damals und es war halt
41:46
überall, also es ist nicht nur, dass es so in einem Projekt war,
41:49
sondern sehr verbreitet, dass du dann zum Beispiel.
41:52
In der C Welt in dein Header Files, wo die Deklaration der
41:55
Funktion drin ist, dann sowas reinschreibst wie Input ist das
41:59
Output ist das Return ist das und ne Erklärung was die
42:03
Funktion macht. Klar du kannst jetzt mit zum
42:05
Beispiel Doxygen ne automatische Code Code Generierung eine Doku
42:08
Generierung machen und kriegst halt hoffentlich eine ganz coole
42:12
Übersicht über deine Software raus, aber es muss einem einfach
42:16
klar sein wie schnell dann diese Dokumentation fehlerhaft ist,
42:20
weil du und benennst die Variablen da drin um, dann passt
42:25
es schon nicht mehr gefühlt. Ja.
42:28
Ich finde, und damit hab ich halt irgendwie auch n clever.
42:30
Das ist für mich eigentlich auch n dont.
42:32
Ich find doch immer die Frage von Dokumentation ist auch immer
42:36
die Frage, für wen wird dokumentiert an dieser Stelle.
42:40
Weil du natürlich Dokumentation auf verschiedenen Ebenen haben
42:43
kannst. Für Entwickler und
42:45
Entwicklerinnen beziehungsweise das Entwicklerteam für User,
42:48
für. Einen bestimmten Fachbereich,
42:52
das Management, was auch immer. Also es gibt ja verschiedene
42:55
Level von Dokumentationen, guter Punkt, ja und wenn du jetzt zum
42:59
Beispiel. Sagst OK, du hast vielleicht ne
43:03
API, die du vielleicht kommentierst für Entwickler, ne
43:08
für das Entwicklerteam, dass du dann zum Beispiel sagst, OK, da
43:11
wird dann zum Beispiel die API beschrieben durch Kommentare an
43:15
der Stelle. Kann man vielleicht machen und
43:18
da wäre ich aber auch nur an der Stelle soweit, dass man, dass
43:21
ich sagen würde, kann man machen, wenn es genau um diese
43:24
spezifischen Domain Informationen geht, die da
43:28
vielleicht benötigt werden an der Stelle oder wenn wirklich,
43:31
vielleicht irgendwie ein komplexer Algorithmus dahinter
43:34
steht, was wir ja schon mal gesagt hatten, das ist im
43:36
Endeffekt genau das, aber sonst würde ich beispielsweise sagen,
43:41
dass man gerade solche API. Auf Entwicklerebene.
43:48
Durch Tests dokumentieren sollte beispielsweise.
43:53
Wenn wir jetzt gerade noch mal bei Dokumentationen sind,
43:55
einfach nur. Noch also, wie gesagt, da gehe
43:57
ich auch mit. Wenn du jetzt natürlich sage ich
43:59
mal, eine öffentliche Schnittstelle anbietet, dann
44:02
muss die dokumentiert sein, damit die Leute dagegen
44:04
entwickeln können, keine Frage, und wenn du das aus dem Code
44:07
heraus automatisiert, sage ich mal, generierst auch absolut in
44:11
Ordnung, ich sage ja auch so Tools wie Doxy gen haben ja ihre
44:14
Daseinsberechtigung und sind auch sehr flexibel und
44:17
vielseitig und gut kontinuierlich konfigurierbar,
44:19
das ist nämlich ein guter Punkt, die müssen halt auch gut
44:22
konfiguriert sein, weil du kannst sehr schnell Doku
44:24
generieren, die nichts aussagt. Aber was da halt einfach ganz
44:30
klar gesagt werden muss ist, dass es ne Menge Arbeit ist, die
44:33
aktuell zu halten und das muss einem klar sein an der Stelle.
44:36
Das ist nicht so n so n einmalding und dann läuft das
44:39
sozusagen, sondern da steckt auch ne Menge.
44:42
Wartung dann dahinter sag ich mal.
44:44
Codedokumentation auch vielleicht noch mal ne eigene
44:48
Folge wert, je nachdem. Absolut.
44:50
Hast du recht darüber? Kann man echt ne Menge reden,
44:53
aber ich glaube wir haben jetzt auch echt eigentlich alles
44:56
soweit abgearbeitet. In verschiedenen Ebenen also
45:01
ausreichend kommentiert. Der war gut.
45:06
Nee, aber weiß ich nicht so alles, was ich so im Kopf hatte,
45:09
wurde entweder. Direkt angesprochen oder im
45:13
Nebensatz erwähnt, auf jeden Fall sehr interessant.
45:17
Vielen Dank dafür Tino erstmal für die fürs nette Gespräch über
45:20
Kommentare. Es hat auf jeden Fall wieder ne
45:24
Menge Spaß gemacht, Fabi ja, auf jeden Fall.
45:26
Nimm das noch mal n bisschen zusammenzufassen.
45:28
Also ich. Also Kommentare sind
45:33
erfahrungsgemäß immer mal wieder im Code drin.
45:38
Man sollte sie aber möglichst vermeiden.
45:41
Und was meinen wir damit mit vermeiden?
45:44
Also es kann ja durch durchaus vorkommen, dass Kommentare im
45:48
Code entstehen und das ist auch vielleicht durchaus sinnvoll,
45:50
dass Kommentare im Code sind, man sollte aber glaube ich immer
45:53
ein großen. Leitsatz oder einen großen
45:57
Leitstern haben, wenn es um Sachen Kommentare geht.
46:00
Und zwar sollte man sich immer Fragen, bringt dieser Kommentar
46:03
Mehrwert. Und wenn er keinen Mehrwert
46:07
bringt, dann lass ihn bitte weg. Also quasi, dass du sagst, es
46:15
ist. Die letzte Instanz nenn ich es
46:20
mal genau, also wenn ich es wirklich nicht schaffe über ne
46:23
saubere Namensgebung abzubilden über vielleicht ja ne bessere an
46:29
besseren Aufbau an Funktion, wenn ich halt einfach denn
46:31
irgendwann nicht mehr schaffe, ist wirklich eindeutig zu
46:33
erklären, dass man auf letzter Ebene sagt Okay, jetzt muss ich
46:37
wirklich mal nen Kommentar ranmachen, weil es sonst nicht
46:39
selbsterklärend ist. Beispielsweise also, wenn man
46:41
sich jetzt ein sehr guter Punkt, wenn man sich jetzt zum Beispiel
46:43
sagt, okay, ich muss jetzt irgendwie eine Information zum
46:47
Code dazu packen sollte. Vielleicht im Vorfeld einmal
46:51
überlegen, gibt es eine andere Möglichkeit.
46:54
Diesen Kommentar sozusagen nicht dorthin zu schreiben, vielleicht
46:58
doch einen Mechanismus, wie ich ihn vorhin einmal genannt habe,
47:02
um to dos zum Beispiel zu vermeiden, solche Sachen einfach
47:05
zu sagen. Gibt es eine Alternative zu
47:07
diesem Kommentar, wenn die Antwort dann wirklich nach einer
47:10
gewissen Überlegung nein heißt, dann schreibt diesen Kommentar
47:13
rein, so, das würde ich halt sagen, also wirklich sozusagen
47:16
die äußerste Instanz zu sagen, Kommentare okay aber wirklich
47:20
mit Bedacht und da kann man, das kann man sich so ein bisschen
47:24
als. Leitstern nehmen würde.
47:27
Ich sagen ja. Und ein sehr guter Leitsatz.
47:30
Und in dem Sinne würde ich auch die Folge abschließen.
47:33
Uns würde es auf jeden Fall super interessieren.
47:36
Liebe Zuhörerin, liebe Zuhörer. Wie?
47:42
Paarung ist bezüglich Kommentare wie ihr das wie du das selber
47:47
handhabst wie du. Auch sowas erlebt hast oder was
47:54
du schon immer, vielleicht gerade als angenommen du bist
47:57
ein Anfänger oder Anfängerin, wie du schon immer über
48:00
vielleicht über Kommentare gedacht hast.
48:04
Wäre auf jeden Fall super interessant und deswegen.
48:07
Auf jeden Fall gerne bei Instagram.
48:09
Auf unserer Podcast Mail. Deine Erfahrungen, deine Ideen,
48:12
deine. Anekdoten, die du dazu erlebt
48:17
hast. Genau, und die ganzen Links,
48:20
also zu Instagram, unser Podcast, Mail und auch zu allen
48:24
anderen Plattformen, die wir bespielen, findest du in den
48:26
Shownotes und in diesem Sinne würde ich sagen, wünschen wir
48:30
euch, wünschen wir dir noch einen wunderschönen Tag.
48:34
Schön, dass du wieder mit dabei warst, dass du zugehört hast und
48:37
ich hoffe, dass du auch was gelernt hast.
48:39
In dem Sinne bis zur nächsten Folge Deine Coding Buddies
48:42
gemeinsam besser. Was?
48:48
Was?