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