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? Was?