Latest / Coding Buddies | Tech & Dev-Mindset / Clean Code #6 - Ist Codeformatierung so wichtig?!

Transcript

Clean Code #6 - Ist Codeformatierung so wichtig?! · Coding Buddies | Tech & Dev-Mindset

0:00
Da eigentlich auch so als Best Practice angesehen wird, was ich
0:03
aber eiskalt ignorieren würde, weil Nein das.
0:08
Das unterstütze ich nicht. Coding Boys, Dein Podcast rund
0:10
um Softwareentwicklung und aktueller Technews.
0:13
Herzlich Willkommen. Was?
0:19
Was? Ja, herzlich Willkommen zur
0:27
neuen Folge des Coaching Bodys Podcasts.
0:29
Schön, dass du wieder eingeschaltet hast.
0:31
Natürlich wieder mal mit dabei, meine Wenigkeit, der Tino und
0:35
natürlich auch der fantastische Fabi.
0:37
Herzlich Willkommen Fabi zur neuen Podcast Folge.
0:41
Einen wunderschönen guten Tag, Tino.
0:44
Wie geht es dir? Mir geht es gut, mir geht es
0:47
fantastisch, ich. Alles in Ordnung soweit.
0:50
Ich hab gute Laune, ich bin irgendwie.
0:52
Voll aufgekratzt. Ich weiß nicht.
0:54
Warum aber? Läuft es, läuft einfach schön.
0:58
Wirkst gar nicht so aufgekratzt da.
0:59
Ich muss doch fragen, was geht ab, fabi?
1:02
Was geht ab? Meine Signaturfrage muss kommen.
1:07
Was geht ab, was geht denn ab? Ja, wir haben ja schon im
1:14
Vorfeld ein bisschen gequatscht, nur zu zweit, nicht zu dritt.
1:18
Die Utorrent hast ja jetzt eben gerade erst eingeschaltet
1:21
logischerweise, und deswegen haben wir schon mal n bisschen
1:23
zu zweit über n Thema gesprochen.
1:25
Und bevor ich das jetzt aber mal vorstelle, möchte ich noch auf
1:29
eine etwas ältere Folge eingehen.
1:32
Und zwar hatten wir ja die Folge, das müsste jetzt auch
1:35
schon n paar Wöchlein her sein. Eine Mythos oder Faktfolge
1:40
gemacht zum Thema, dass es keine Frauen in der
1:43
Softwareentwicklung gibt und haben da mal drüber gesprochen,
1:46
ob das n Mythos ist oder n Fakt und sind zu dem Schluss
1:48
gekommen, dass es leider noch n bisschen mehr Fakt als n
1:51
bisschen mehr doch n bisschen mehr Fakt als Mythos ist.
1:54
So rum. Zumindest aus unserer Sicht.
1:57
Aus unserer Sicht aber sich die Tendenz abzeichnet, dass doch
2:02
die Frauenquote da steigt über die Jahre, was natürlich eine
2:05
super schöne Entwicklung ist. Und hatten ja einen Aufruf.
2:09
Gestartet in der Folge, dass sich doch bitte aus unserer
2:11
Community alle Frauen melden sollen.
2:15
Die. In der Softwareentwicklung oder
2:17
zumindestens Berührungspunkte damit haben dort in dem Bereich
2:21
unterwegs sind und mal ihre Erfahrungen schildern oder was
2:24
sie vielleicht glauben. Warum es so sein könnte, dass es
2:28
halt immer noch quasi. Mehr Männer als Frauen gibt.
2:32
Und da haben wir ja n paar Rückmeldungen bekommen und eine
2:35
fanden wir ganz besonders cool, da haben wir ne Mail bekommen.
2:38
Magst du vielleicht mal davon berichten?
2:41
Ja, sehr gerne. Susanne hat uns nämlich
2:43
geschrieben und hat uns so n bisschen ihre Geschichte
2:46
erzählt, wie sie zum Beispiel in die Softwareentwicklung gekommen
2:48
ist und hat uns auch so n bisschen ja mitgeteilt oder so
2:53
Erfahrung geschildert, was wir ja auch, was viele ja irgendwie
2:57
kennen, so leider Gottes ne, dass zum Beispiel so, dass die
2:59
als Mädchen auch nicht so viel mit Computern zu tun hatte als
3:02
Kind und das zum Beispiel der Informatikunterricht in der
3:06
Schule halt langweilig war, das hast du ja auch schon
3:08
geschildert, Tino. Und sie war auf jeden Fall gut
3:13
in Mathe und Bio und konnte in ihrer Schule auch in so ne
3:17
Klasse gehen, wo extra so eine extra naturwissenschaftliche
3:21
Klasse und auch da waren relativ wenig Mädchen vertreten.
3:26
Was sie geschildert hatte und nach dem Abi hat sie dann
3:30
Biomathematik studiert. Interessanter Studiengang auf
3:34
jeden Fall, macht aber Sinn von dem, was ihre Stärken waren und
3:38
hat dann aber auch mitgekriegt, dass dort in diesem Studiengang
3:41
wahrscheinlich meinte sie, durch die Biologie mehr Frauen als
3:46
Männer waren in diesem Studiengang vertreten.
3:48
Und in diesem Studiengang hatte sie das erste Mal
3:51
Berührungspunkte mit der Informatik.
3:54
Vor allem, weil sie auch n sehr guten Juniorprofessor hatte, der
3:59
das wohl sehr schmackhaft gemacht hat.
4:01
Dieses Thema, was natürlich total cool ist.
4:03
Und was mir auch wieder zeigt, dass es wichtig ist, das Ganze
4:06
auch irgendwie cool zu machen, weil wie gesagt langweiliger
4:09
Informatikunterricht bedeutet, interessiert mich nicht, aber
4:12
wenn es dann doch irgendwie cool aufbereitet ist, dann macht das
4:15
irgendwie. Sinn?
4:16
Ja, das deckt sich ja dann komplett mit den Punkten, die
4:19
wir da so genannt hatten, also dass sie quasi in der Schulzeit
4:22
die gleichen Erfahrungen gemacht hat.
4:25
Und dann aber halt diese eine Juniorprof schon dafür sorgen
4:28
kann, dass man doch Interesse an diesem Thema gewinnt quasi und
4:32
merkt, Hey, das ist doch vielleicht doch was, was mir
4:35
Spaß machen könnte und vielleicht vertiefe ich mich
4:37
mal. Denn doch in dem Bereich, zum
4:39
Beispiel Softwareentwicklung und.
4:41
Das hat sie auch gemacht im Master, dass sie das Halt sehr
4:44
Informatik lastig dann ausgelegt hat.
4:47
Ja, und sicherlich, weil da so dieser Grundstein gelegt wurde.
4:50
So wie ich das verstanden hatte, und das finde ich halt mega cool
4:54
und man muss natürlich sagen, dass so Naturwissenschaften.
4:58
Welche Studiengänge, oft auch ne Schnittstelle haben, also dass
5:02
es oftmals Bereiche gibt, wo die Informatik eine Rolle spielt und
5:06
man da natürlich dann relativ schnell die Tür öffnen kann, um
5:10
mal in diesen Bereich reinzuschauen.
5:12
Genau, und das ist halt da natürlich ne super Gelegenheit
5:14
gewesen und ich find es auch sehr cool Suse, falls du diese
5:17
Folge hörst, dass du das auch gemacht hast, fand ich auf jeden
5:22
Fall auch sehr beeindruckend. Ja, mega cool und auf jeden Fall
5:25
hat sie dann auch noch geschrieben, dass sie.
5:27
Halt eben sich so n bisschen als halb Quereinsteigerin sieht,
5:30
weil sie halt eben nicht Informatik studiert hat, aber
5:32
trotzdem halt sehr gerne danach in die Softwareentwicklung gehen
5:35
wollte und dann auch noch n dreimonatigen Intensivkurs
5:39
gemacht hat und dann sozusagen mit ihrem.
5:42
Studium mit diesem informatiklastigen Studium was
5:46
sie sich selbst gewählt hat Plus zum Intensivkurs ist auch dann
5:49
geschafft. Hat den Einstieg in die
5:50
Softwareentwicklung zu machen. Ja und jetzt schon seit mehr als
5:53
8 Jahren als Softwareentwicklerin arbeitet.
5:57
Und so viel erstmal zu Ihrer Geschichte.
5:59
Was ich aber sehr interessant fand und was wir beide ja sehr
6:01
interessant fanden, war ja der Punkt, dass nach ihrer Schätzung
6:05
der Frauenanteil im Softwarebereich in der Firma, in
6:08
der sie arbeitet, bei ungefähr 40% liegt und das ist halt echt
6:11
schon relativ hoch, weil wir haben ja auch gesagt, dass wir
6:14
das so von unserer Arbeit gar nicht so kennen, es du aber auch
6:19
zum Beispiel einen Freund hast, der ja auch in der Firma
6:22
arbeitet, wo auch einige Softwareentwicklerinnen
6:24
arbeiten, was natürlich cool ist, aber ein Anteil von 40% ist
6:28
natürlich schon echt stark. Und das ist natürlich auf jeden
6:31
Fall noch mal so ein bisschen so ein kleiner, so ein kleines
6:35
Gegenbeispiel zu dem, dass nur Männer in der
6:38
Softwareentwicklung sind. Quasi ein Beispiel dafür, dass
6:42
es halt eben vielleicht nicht überall.
6:46
Sozusagen so ist, dass es keine Frauen gibt, sondern dass es
6:49
eher ein Mythos als ein Fakt ist.
6:51
Und das ist natürlich cool, also sozusagen genau dieses Beispiel
6:54
von Susanne zu. Hören vielleicht.
6:57
Ist da einfach unsere Umgebung, in der wir arbeiten?
7:00
Vielleicht ja auch noch n bisschen hinterher?
7:01
Es kann ja auch sein, ne, dass es so in anderen Firmen da schon
7:06
besser aufgeteilt ist, was ja einfach nur zu begrüßen wäre.
7:11
Auf jeden Fall ein super Beispiel, dass es, dass es sie
7:14
gibt, die Softwareentwicklerin, und es hat uns sehr gefreut,
7:17
Suse, vielen, vielen Dank noch mal für die Nachricht und dass
7:20
wir auch die Erlaubnis von dir bekommen haben, dass hier im
7:22
Podcast zu teilen, weil vielleicht motiviert das jetzt
7:24
auch die eine oder andere höhere.
7:27
Doch weiterzumachen oder damit anzufangen, auch über n
7:29
Quereinstieg nachzudenken oder vielleicht auch während des
7:33
Abiturs sich zu denken, hey, so n Informatikstudium könnte doch
7:36
ganz cool sein. Genau.
7:37
Und wenn du, liebe Zuhörerin, dir jetzt sagst, ach Mensch, das
7:40
ist ja echt spannend. Bei mir ist das tatsächlich auch
7:43
so wie bei Suse. Dann schreibt uns auch einfach
7:47
mal über die Podcast Mail oder wenn es zum Beispiel.
7:50
Auch. Wie bei uns halt auch, sag ich
7:52
mal. In der Ferne liegt das irgendwie
7:54
der Frauenanteil und der Männeranteil quasi ausgeglichen
7:57
sind. Dann schreibt uns auch mal wie
7:58
es bei euch ist, wenn ihr da Lust drauf habt.
8:01
Die Podcast Mail ist auf jeden Fall in den Shownotes verlinkt.
8:05
Ganz genau. Und ich würde sagen, dann können
8:09
wir jetzt ja zu dem. Thema der heutigen Folge kommen
8:13
mir ist gerade das Wort Thema nicht eingefallen.
8:15
Schwieriges Wort. Und zwar Fabi wollen wir heute
8:20
ja noch mal. Eine Folge zum Thema Cleancode
8:23
machen. Das heißt, unsere Reihe
8:26
fortführen. Wir haben ja ein gutes Feedback
8:27
dazu bekommen und finden ja das Thema selbst auch sehr wichtig
8:30
und spannend und deswegen drehen wir das Rad weiter.
8:34
Eine neue Folge cleancode und zwar soll es heute in der ist
8:38
das jetzt schon die 6. Folge Oh mein Gott nagel mich
8:41
nicht drauf fest, aber wir haben auf jeden Fall schon einige dazu
8:43
gemacht, fünft oder sechst. Ne und auf jeden Fall geht es
8:49
heute um das Thema. Das klingt erstmal n bisschen
8:52
trivial, aber ich denke, dass wir da auch einige Punkte zu
8:54
finden werden. Halt dich fest, ich halt mich
8:58
Formatierung, auch wenn fast schon jetzt hab ich es gesagt,
9:01
bevor du dich festgefallen festgabe bevor du dich
9:04
festgehalten hast. Genau das Thema ist Formatierung
9:07
Code Formatierung, das ganze Projekt, die Formatierung
9:11
allgemein und. Das ist ein Thema, da scheinen
9:17
sich auch die Geister, gibt es unterschiedliche Ansichten,
9:19
unterschiedliche Vorlieben, wie man was formatiert.
9:24
Ich möchte jetzt ja auch nicht irgendwie darauf kommen, was
9:26
richtig und falsch ist. Aber vielleicht, dass man mal so
9:30
n bisschen herauskristallisiert, was n guter Stil ist und was er
9:33
kein guter Stil ist. Also ich finde jetzt nicht um
9:36
mal so n kleinen so n kleines Vorwort da mal zu geben.
9:40
Ich finde nicht, dass es ein absolut richtig und ein absolut
9:43
falsch gibt, also es ist halt wirklich immer so ein bisschen
9:47
definitionssache am Ende auch, aber ich glaube, dass man da
9:50
trotzdem jetzt so ein paar Best Practices mit auf den Weg geben
9:53
kann für. Die sich vielleicht gerade am
9:56
Anfang der Reise befinden, also der Reise zum Softwareentwickler
10:00
softwareentwicklerin, dass man darauf auf jeden Fall n paar
10:04
gute Punkte mitgeben kann. Aber was man jetzt so fand.
10:06
Ja, aber Tino jetzt mal ernsthaft.
10:08
Also Formatierung von Code ist doch völlig egal, oder?
10:13
Und das war es auch schon mit der Folge.
10:14
Das war unser unsere Best Practice, macht was ihr.
10:17
Wollt, Hauptsache ihr. Schaltet nächstes Mal wieder
10:20
ein. Nein, ganz so einfach ist es
10:23
natürlich nicht. Ja, finde ich auch.
10:27
Also ich, ich finde das ist das das das Thema klingt erstmal
10:30
echt irgendwie trivial und auch sehr.
10:35
Schnell vernachlässigbar, dass man sich so denkt.
10:37
So, ja komm, es gibt wirklich Wichtigeres als eine
10:40
Formatierung vom Code. Aber ich kann auf jeden Fall
10:45
gerne dann auch vielleicht n bisschen später auch noch mal n
10:48
in in in Beispiel nennen. Was ich zum Beispiel auch
10:51
wirklich sag, jetzt mal am eigenen Leib erlebt habe im
10:56
punkto Code Formatierung, was wirklich unglaublich nervig sein
11:00
kann. Und aber wir können ja erstmal
11:04
mit mit den mit n paar Low hanging Fruits anfangen.
11:09
Wenn es jetzt zum Beispiel um Code Formatierung geht, weil du
11:11
hast ja gesagt es geht n bisschen darum, dass man sich
11:13
auch im Team dass man ne Einheitlichkeit vom Code hat,
11:18
dass man quasi auch irgendwie Absprachen hat, woran man sich
11:22
vielleicht hält und. Was wäre denn vielleicht so das
11:27
erste, was dir einfällt, wenn es um Formatierung geht?
11:31
Die. Die dir jetzt als erstes so in
11:35
den Kopf kommt. Ja, also das erste wäre für
11:40
mich, ich bringe jetzt mal n Beispiel und dann können wir ja
11:43
sagen was daraus resultiert. Ne weil ich würd halt gern noch
11:45
so n paar Punkte herauskristallisieren, warum das
11:48
denn wichtig ist. Ne und so.
11:52
Absolute Basics und da machen sich viele wahrscheinlich auch
11:55
keine Gedanken mehr heutzutage drum, weil ja auch so moderne
11:59
Ideis einem das sehr viel abnehmen.
12:03
Sind für mich halt so diese horizontale und vertikale
12:07
Formatierung von Code und was ich damit meine ist zb wie lang
12:14
eine Zeile ist eine Codezeile. Und oder halt auch die
12:21
klassische Einrückung von Code, um quasi gültigkeitsbereiche
12:27
besser. Grafisch darzustellen nenne ich
12:30
es mal. Was ich interessant finde ist,
12:32
wenn du jetzt von der. Was heißt horizontalen
12:36
Begrenzung sprichst, wenn man sich mal genau anguckt und mal
12:41
so ne IDE schnappt und da mal sag ich jetzt mal genauer
12:43
hinguckt, dann ist es vielleicht für Neuankömmlinge in der.
12:48
Softwareentwicklung wenn man eine ID hat vielleicht.
12:53
Komisch, dass in dem Editor irgendwo auf der Seite n
12:57
vertikaler Strich ist. Der ist dann meistens eher
13:00
rechts irgendwo an der Seite und vielleicht eventuell weiß man
13:04
nicht genau was soll denn das genau sein?
13:05
Ne, also ich hatte ganz am Anfang dachte ich mir auch so ja
13:08
okay cool keine Ahnung also ich glaube damals gab's gefühlt
13:11
sowas noch gar nicht, irgendwann kam das dann und das ist halt
13:15
zum Beispiel auch sowas wie vielleicht so eine
13:17
Voreinstellung von der IDE die sagt Okay deine deine
13:22
Blattbreite in Anführungsstrichen.
13:25
Ist jetzt hier vorbei und du solltest nicht darüber
13:27
schreiben. Also das ist ja glaube ich das,
13:30
was du als ein Beispiel meintest, nur dass man sich das
13:33
vielleicht ein bisschen besser vorstellen kann, oder wenn man
13:35
jetzt als Neuankömmling sozusagen mal eine IDE aufmacht,
13:38
also so eine Entwicklungsumgebung und sich
13:40
denkt, ach guck mal, Tatsache, da ist ja wirklich so ein
13:43
Strich, jetzt weiß ich, was der zu bedeuten hat.
13:46
Also dazu muss man natürlich sagen, also.
13:49
Der Strich ist dafür da, dass du halt gedanklich siehst, bis wo.
13:52
Und das meinte ich halt auch mit IDS nehmen dir die Arbeit ab,
13:55
weil es halt ne gewisse Autoformatierung nach Regeln
13:57
gibt und die ID würde halt ab diesem Strich halt n
14:00
Zeilenumbruch machen und sinnvoll mit gewisser Logik
14:04
halten, Zeilenumbruch nicht einfach nur an der Stelle quasi
14:07
abschneiden, weil das wäre ja dann wahrscheinlich würde das
14:10
ein Syntaxfehler führen, aber es wird halt ein logischer
14:13
Zeilenumbruch eingebaut, das Ganze ist aber natürlich auch
14:17
ein bisschen historisch bedingt also.
14:20
Es geht ja darum vor allem, dass in früheren Jahren man gar nicht
14:25
so eine hohe Auflösung hatte auf seinem Bildschirm und
14:28
dementsprechend nicht so viel Pixel zur Verfügung wie
14:31
heutzutage, wie beispielsweise bei einem 4 K Monitor.
14:36
Da kannst du natürlich ordentlich in die Breite gehen
14:38
und kannst alles noch gut lesen und erkennen, aber wenn man sich
14:42
jetzt mal vorstellt, man hat nicht so viel zu sehen, dann
14:44
willst du ja auch nicht anfangen rum zu scrollen, dass du immer
14:47
von links nach rechts scrollen musst um dein Code lesen zu
14:50
können, weil das ist nämlich jetzt so der erste wichtige
14:52
Punkt, weswegen? Formatierung ne Rolle spielt ist
14:55
einfach die die Lesbarkeit ne gute Lesbarkeit des Codes
14:59
fördert natürlich auch ne schnellere Arbeitsweise und da
15:04
ist das so traditionell auch her sag ich mal beziehungsweise.
15:08
Es spielt immer noch ne Rolle, weil du würdest es ja immer noch
15:11
schaffen, wenn du möchtest. So lange Code seien zu
15:14
schreiben, dass da auch deine Auflösung nicht mehr ausreicht.
15:18
Und du wieder scrollen musst. Und das Ganze natürlich wieder
15:21
zu einer unglaublich schlechten Lesbarkeit führt.
15:25
Bis hinzu Sprachen wie beispielsweise Java, wo du
15:29
einfach alle Zeilen hintereinander hängst.
15:32
Du musst die ja nicht in neue Zeilen packen.
15:34
Also jedes Codesegment sage ich mal, jede Anweisung, und das ist
15:40
natürlich ein schlechter Stil, dann ist es kann man gerne
15:43
machen, aber es wäre für mich jetzt ein schlechter Stil und
15:47
nicht best practice, das zu tun und deswegen achtet man halt zum
15:50
Beispiel auf diese Zeilenlänge. Und in der Vertikalen ist halt
15:54
ein sehr, sehr wichtiger Punkt dieser Einrückung.
15:56
Was ich schon meinte. Klassisch, wenn du eine Funktion
16:01
definierst, dass dann der Code der Funktion quasi genau um 1
16:06
nach rechts geschiftet wird, um ein Tab meistens.
16:09
Das ist ja auch immer so eine Definitionssache.
16:12
Was ist ein Tab, sind es 2 Leerzeilen Zeichen?
16:16
Oder 4 auch wieder Geschmackssache.
16:19
Ich persönlich bin Fan von 4 muss ich sagen, das ist aber
16:22
auch mal anmerken, ist aber. Witzigerweise auch n Unterschied
16:25
ich also mittlerweile sind die IDS darauf eingestellt, dass
16:28
sozusagen für ein Tab Leerzeichen verwendet werden.
16:30
Es gab aber mal ne Zeit. Ist jetzt auch nicht so lange
16:34
her, weil es klingt immer so, wie ja damals vor 100 Jahren.
16:39
Es ist nicht so lange her, aber da gab es halt auch eben bei
16:42
IDES den Fall, dass zum Beispiel N tappen Tab war.
16:46
Was durchaus auch n Unterschied gemacht hat, weil n Tab auch
16:49
quasi von der Formatierung her nicht immer quasi in in jedem
16:53
Editor dann auch die gleiche Länge hatte.
16:56
Und wenn du zum Beispiel NN Tab gemacht hast und sag ich jetzt
17:00
mal den Tab gelöscht hast, konnte es halt sein, dass zum
17:04
Beispiel die irgendjemand hat zum Beispiel Leerzeichen
17:07
verwendet. Irgendjemand hat wirklich Tabs
17:08
verwendet und mittlerweile glaube ich.
17:11
Ist ein. Tabak ersetzt mit Leerzeichen.
17:13
Genau, genau, ja. Aber das ist n interessanter
17:16
Punkt, weil der ist zum Beispiel, das ist mir auch
17:18
früher mal aufgekommen, und das kam, ich weiß es gar nicht mehr
17:22
genau, was kam, glaub ich auch dann zu Konflikten im Code unter
17:25
Umständen. Waren auf jeden Fall komische
17:29
Verhalten, also war n komisches. Verhalten und deswegen wird
17:33
jetzt eigentlich in der Regel, denn wenn du Tab drückst,
17:35
kriegst du halt deine Einrückung, die definiert es,
17:38
wird aber halt quasi mit Leerzeichen umgesetzt, sag ich
17:40
mal. Genau.
17:43
Und interessanterweise gibt es ja aber auch sprachen, die das
17:47
einfach voraussetzen, dass man das tut, wie beispielsweise
17:50
Python aus unserem Grundlagenkurs.
17:54
Java hingegen könntest du zum Beispiel sagen, OK, ich rück
17:56
nichts ein und es würde trotzdem kompilieren.
18:01
Und bei Python ist es aber so, dass dieses Intent, also diese
18:05
Einrückung erwartet wird und der Interpreter dann halt einfach n
18:09
Fehler wirft und sagt ja nee, hier da wird ne ne Einrückung
18:13
erwartet zum Beispiel. Nach deiner If Bedingung, also
18:17
der Code Anteil von von dem IF oder auch in der Funktion und
18:21
das find ich halt ganz spannend, weil das erzwingt diese
18:25
Formatierung dann auch. Ja, obwohl ich das, obwohl ich
18:29
immer noch n bisschen komisch finde, dass Python sagt.
18:33
Das Zeilenende wird durch einen Zeilenumbruch sozusagen
18:36
markiert, weil zum Beispiel bei Java ist es ja ein Semikolon.
18:41
Und ja, also ich fand das am Anfang genau.
18:45
Am Anfang fand ich es interessant, dieses Konzept so,
18:48
aber es gibt ja bei einigen Programmiersprachen aber ganz am
18:50
Anfang bei Python hat mich das auf jeden Fall schon so ein
18:52
bisschen so verwundert. Ja, es verhindert ja dann zum
18:56
Beispiel, was ich vorhin meinte, dass du einfach alle Anweisungen
18:59
in eine Zeile schreibst, was du mit Java theoretisch machen
19:01
könnte. Ich weiß nicht, wer das tut,
19:04
aber. Wäre theoretisch möglich.
19:05
Und Python? Würde es also.
19:07
Per Definition schon verhindern oder sagen, das geht nicht.
19:12
Ich denke mal auch hinsichtlich der der Codeformatierung.
19:16
Auf jeden Fall sind das so die ersten beiden Punkte, die viele
19:19
als trivial wahrscheinlich ansehen, gerade aber auch, weil
19:22
ID is das Auto formatieren sehr gut drauf haben mittlerweile.
19:25
Wenn man jetzt wirklich alles per Hand das noch machen müsste
19:28
mit dem Einrücken und allem würde mich mal interessieren wie
19:31
viele Leute da noch richtig wert drauf legen und das alles
19:33
richtig ordentlich machen das halt denn auch zum Beispiel jede
19:36
Funktion gleich eingerückt wird oder beziehungsweise jede
19:39
Einrückung immer 4 Leerzeichen sind und nicht 2 oder ob du in
19:43
einem Fall sagst Ach komm 2 ist in Ordnung.
19:46
Oder 4. Halt ne.
19:48
Aber das finde ich, ist jetzt auf jeden Fall ein nächster
19:51
spannender Punkt. Klar, also ich handhabe das auf
19:56
jeden Fall so, dass ich quasi Code schreibe.
19:59
Dann vielleicht. Sagen wir mal, man schreibt ein
20:03
If macht Klammer auf. Beispielsweise wenn wir jetzt
20:06
nicht bei Python sind, weil da wird das nicht mit Klammer
20:08
aufgeschrieben. Aber wenn ihr jetzt solche bei
20:10
keine Ahnung Java oder type Script oder frag mich nicht
20:14
verschiedenen anderen Sprachen, wo quasi die IF Bedingung
20:18
geklammert wird auf jeden Fall und du schreibst dann zum
20:21
Beispiel If Klammer auf und schreibst deine Bedingungen da
20:24
rein. Dann schreib ich das meistens
20:25
einfach hintereinander weg und mach dann hinterher n
20:29
autoformat, weil dann quasi die IDI meistens sagt OK es kommt n
20:33
if dann n Leerzeichen und dann Klammer auf so beispielsweise
20:36
ne, also es wird so n bisschen formatiert, halt n bisschen
20:39
eingerückt und sowas das ist halt so ne gängige Praxis.
20:42
Ich schreib Code eigentlich runter, hab aber natürlich dann
20:45
auch so weiß ich sowas wie Leerzeichen Leerzeilen also ein
20:49
Enter wenn du jetzt zum Beispiel keine Ahnung wie du meintest du
20:51
schreibst eine Funktion und dein Funktionskopf ist dann in einer
20:54
anderen Zeile als halt dein Funktionskörper.
20:58
Und so weiter. Das sind ja so Standard Dinge,
21:00
aber so jetzt irgendwie Leerzeichen oder so, da halte
21:03
ich jetzt nicht für an und sag jetzt if Leerzeichen und und
21:07
genau dann klammer auf so weißt du, das ist eigentlich relativ
21:10
wurst und ich schreibe das dann einfach so runter und dann mach
21:12
ich einmal autoformat was ich sehr interessant finde ist zum
21:16
Beispiel der Punkt, wenn wir jetzt gerade im Bereich vom von
21:19
vom Team, also in der Teamzusammenarbeit sprechen.
21:23
Man kann natürlich sagen, ja gut klar Lesbarkeit,
21:26
Verständlichkeit ist ja wichtig. Richtig ne.
21:29
Wenn wir jetzt aber noch mal wirklich auf die Effizienz der
21:31
Zusammenarbeit im Team gucken und.
21:35
Ist das ist eine Sache, die habe ich tatsächlich mal erlebt, weil
21:38
natürlich hast du Autoformate in IDES, aber dieses Autoformat in
21:42
IDIS kannst du ja selber einstellen, ne, und das ist uns
21:47
auf jeden Fall mal in einem alten Projekt von mir
21:50
unglaublich auf die Füße gefallen.
21:53
Weil du musst dir vorstellen, einer erstellt ein neues File,
21:56
schreibt da drin und committed das und pusht das so.
22:00
Irgendjemand zieht sich die neuen Änderungen vom von vom
22:03
Remote Repository und du hast sie dann und arbeitest dann
22:07
selber da an an dem an dem Pfeil irgendwann vielleicht eine Woche
22:10
später und baust neues Feature ein.
22:13
Musst irgendwie an dieses an diese Klasse ran dann zum
22:17
Beispiel ich dann schreibe ich da dran und mache genau das was
22:20
ich meinte ich schreibe dann irgendwie irgendwie eine IF
22:22
Bedingung irgendwas hin else noch mach autoformat und auf
22:26
einmal dass sich der ganze Code verrückt oh vielleicht merk ich
22:30
es auch nicht. In dem Fall war es eher so n hä
22:33
ist ja komisch na ja gut ist erst mal so so Anomaliemäßig
22:38
abgetan ist nicht so wild weil es war so ich hatte 4
22:42
Leerzeichen als Tab wie du es auch bevorzugst fand ich auch
22:45
gut, finde ich immer noch gut. Als Einrückung und irgendjemand
22:50
anders im Team hatte 2 Leerzeichen eingestellt in
22:53
seiner IDE, das heißt? Das File war in der Einrückung,
22:58
also jeder Einrückung hatte 2 Leerzeichen.
23:00
Ich habe Autoformat gemacht, alles wurde auf 4 Leerzeichen
23:03
eingerückt, das heißt im Endeffekt war die.
23:06
Zeile hatten Change gehabt. Jede.
23:07
Zeile hatten Change gehabt, genau so was erstmal so war
23:12
sowie ja gut, ok komisch. Naja, weiß ich nicht.
23:17
Es sind ja 4 Leerzeichen so eigentlich gesetzt im Team.
23:21
Also machen wir das so packe ich mal so mit rein, so wie gesagt
23:25
getan irgendwann später. Wieder das gleiche Verhalten und
23:30
dann kommt man irgendwann auf diesen.
23:32
Also es war dann so so n so n wieso ne Dynamik wo quasi
23:36
bestimmte Files immer auf 2 zurückgesetzt wurden, also auf 2
23:39
einrückungslehrzeichen und dann wieder auf 4
23:41
einrückungslehrzeichen und das ging die ganze Zeit so hin und
23:43
her bis irgendwann jeder so hart davon genervt war und sich
23:46
dachte warum zur Hölle haben wir so viele Changes bei uns, dass
23:51
man dann irgendwann sagte Moment Halt Stopp, wir gehen jetzt mal
23:53
alle zusammen die Ideen durch was da drin konfiguriert ist und
23:57
das ist halt eine Sache ich. Lesbarkeit, Verständlichkeit,
24:01
Codeformatierung ist wichtig. Das ist auch gut, wenn man die
24:04
einstellt. Nummern sollte sie innerhalb
24:06
eines Teams auch gleich einstellen, weil ansonsten kommt
24:09
es. Ansonsten wird es echt krude.
24:12
Das ist halt auch gleich der nächste wichtige Punkt.
24:15
Also klar, Formatierung ist einerseits Lesbarkeitsaspekt,
24:20
der sehr wichtig ist. Sorgt aber auch dafür, dass zum
24:25
Beispiel der Code einheitlich aussieht.
24:26
Und das ist halt genau das, was du gerade meintest, dass du
24:29
entweder zum Beispiel 4. Leerzeichen, einrückst oder 2,
24:34
also pro valide Einrückung sag ich mal.
24:37
Also ein Tab sinnbildlich und es ist so gesehen egal ob 2 oder 4.
24:44
Das ist eher so ne Präferenz des Entwicklers was er optisch
24:47
schöner findet. Ich finde das also bei 2 finde
24:51
ich fühle ich mich so ein bisschen beim Code lesen unwohl,
24:53
wenn man das so sagen kann, also ich.
24:55
Guck halt lieber. Auf Code, der mit 4 Leerzeichen
24:57
eingerückt wird, weiß nicht warum, aber es ist auch so eine
25:00
gewohnheitsding glaube ich. Das heißt, fühle ich also wenn
25:04
ich den Code so sehe, dann fühle ich mich wohler, ihn zu lesen
25:07
und zu verstehen. Aber ein Punkt, den du ja da
25:10
gerade mit genannt hast oder gezeigt hast, warum es wichtig
25:13
ist, ist ja auch wirklich, dass es einheitlich im Team ist.
25:16
Das heißt, es muss eine Teamvereinbarung geben an allen,
25:19
also mit allen Leuten, die an dieser codebasis mitentwickeln.
25:25
Einfach nur, wenn. Macht was er will, kommst du ja
25:29
genau zu diesem Problem, was du gerade beschrieben hast.
25:32
Ja. Richtig, und deswegen ist es gar
25:35
nicht so wichtig, ob 4 Zeichen einrücken oder 2.
25:38
Wichtig ist nur, dass es einheitlich ist, dass es n
25:41
gemeinsames Verständnis im Team gibt und Commitment darauf, dass
25:44
man halt quasi sagt Okay, wir haben sozusagen unseren eigenen
25:48
Standard, wie wir Code formatieren.
25:53
Ich finde. Man weiß ja auch jeder Bescheid
25:54
halt. Ich finde die einfachste
25:56
Herangehensweise für dieses, für diese Art und Weise ist, sagen
26:00
wir mal, das Team benutzt jeder die gleiche ide.
26:03
Das wäre auf jeden Fall schon mal eine erste Herangehensweise,
26:06
das nicht schlecht wäre, dass jeder die gleiche id verwendet
26:09
und ich bin halt einfach ein Fan davon eine IDE von der
26:13
Einstellung her so zu lassen wie sie ist, weil dann hast du also
26:16
außer einer IDE hat jetzt irgendwie keine Ahnung 20
26:20
Leerzeichen in der Einrückung, aber im Normalfall ist es ja
26:22
wirklich auch. Auf einen schönen, Leserlichen,
26:26
gut formatierten Code zurecht. Geschnitzt sag ich jetzt mal,
26:30
also voreingestellt. Das ist find ich.
26:32
Also ich hatte damit noch nie n Problem und für mich macht es
26:35
einfach Sinn zu sagen OK machen wir es so einfach wie möglich
26:38
und nehmen einfach die Einstellung von der IDI und
26:41
lassen die so wie sie ist und dann gibt es quasi.
26:44
Keine jeder stellt mal hier n bisschen was ein und hier n
26:46
bisschen was und so weiter also weniger Stellschrauben,
26:50
einfachere Einstellungen so. Ja, da muss man natürlich sagen,
26:54
dass es ja auch gewisse Coding Standards gibt, die jetzt nicht
26:57
nur von deinem Team definiert werden, sondern die so
27:00
allgemeingültig sind. Und da hast du ja zum Beispiel
27:03
das 4 Zeichen Einrückung Standard ist vielleicht auch 22
27:07
oder 4 sagen wir es mal so, aber es gibt jetzt wenige Leute die
27:12
jetzt 351 oder irgendwie sowas nehmen.
27:16
Richtig creepy. 1 wäre so richtig also auf gut deutsch
27:20
Scheiße zu lesen. Aber klar, du hast halt wie
27:27
gesagt einmal dieses Commitment im Team.
27:28
Andererseits sind diese Ideen schon so mit Best Practices
27:32
vorkonfiguriert in der Formatierung in dieser
27:34
Autoformatierung, dass man da eigentlich schon fast alles mit
27:38
abdeckt. Es gibt halt dann noch so ein
27:39
Paar, sagen wir mal Vorlieben oder Präferenzen so.
27:44
A oder b mäßig also, dass es so 2 Möglichkeiten gibt, wie zum
27:48
Beispiel 4 Leerzeichen oder 2. Was wir jetzt ja ausgiebig
27:51
versprochen haben. Ne anderes Beispiel wäre noch
27:55
was, auch wenn man sehr witziges Diskussionsthema ist, weil da
27:58
hab ich auch ne klare Ansicht. Weil wir jetzt zum Beispiel Java
28:02
hatten und die die IF Bedingung. Und die Einrückung haben wir
28:07
drüber gesprochen. So in Java sind aber so Scopes,
28:10
ja mit geschweiften Klammern definiert, das heißt?
28:14
Geschweifte Klammer auf, dann kommt der die Codeanweisung
28:17
rein, die deine wenn deine If Bedingung erfüllt ist und
28:20
geschweifte Klammer zu auch mal ganz kurz für Leute die jetzt
28:23
Java nicht entwickeln weil in Python gibt es das Halt nicht.
28:28
Und dann ist halt die Frage, auf welche Zeile kommt die öffnende,
28:32
die öffnende Klammer, also der geschweifte Klammer auf da gibt.
28:35
Es genau eine Antwort zu. Ja.
28:38
Für mich auch, aber in der in der Realität gibt es 2 Ansätze.
28:43
Ich habe beide auch schon verwendet.
28:44
OK, dann sag mal bitte was deine deine Präferenz ist.
28:49
Na, die geschweifte Klammer auf in der gleichen Zeile wie die
28:52
IF. OKOK das finde ich gut.
28:56
Wir können weiter zusammen Cohen, weil das sehe ich
28:58
genauso, für mich ist das auch einfach so, die Practice, die
29:02
ich mir da irgendwie über die Jahre angeeignet hab, obwohl ich
29:05
in Projekten gearbeitet hab, wo es nicht so war.
29:08
Und da ist die öffnende Klammer auf ne neue Zeile gekommen.
29:11
Das heißt, du hattest deine If Anweisung, also die If Bedingung
29:14
neue Zeile Klammer auf neue Zeile, dann warst du im Scope
29:18
von Deiner If Bedingung hast den Code geschrieben, noch mal ne
29:21
neue Zeile Klammer zu neue Zeile, weiter geht es.
29:24
Das habe ich heute das Konto machen im Studium.
29:26
Das ist, das ist auch ein absolut valider Weg, und das
29:29
machen auch einige. Zum Beispiel habe ich das
29:32
Gefühl, dass das so in der C. Welt verbreitet ist.
29:35
Haben wir nicht gelernt, dass in C das so gemacht wird?
29:39
Ja, vielleicht ist es in diesem ganzen C.
29:41
Universum könnte sein bei so CC Plus Plus habe ich das Halt
29:45
gesehen in den Projekten und C. Sharp ja stimmt, das hatten wir
29:48
glaube ich in der Community mal das Thema, dass das da
29:50
eigentlich auch so als Best practice angesehen wird, was ich
29:53
aber eiskalt ignorieren würde, weil das.
29:58
Das unterstütze ich nicht. Schreibt uns doch mal was eure
30:00
Vorlieben sind in Sachen wo. Kommt die Klammer her, kannst du
30:04
es. Bitte, schreibt uns.
30:05
Wir müssen gucken, was die Wahrheit ist.
30:09
Dann wird das durchgezählt und dann wird gevotet und dann wird
30:13
das so gemacht. Und dann will ich nichts mehr
30:16
hören. Es sei denn natürlich, es kommt
30:19
in ne neue Zeile, dann Veto. Auf jeden Fall ist das auch
30:25
wieder n klassisches Beispiel für.
30:27
Es gibt nicht richtig oder falsch.
30:30
Ja, also ja. Aber es gibt halt diese 2
30:34
Möglichkeiten und dann Herr Veto und da ist halt einfach wichtig,
30:38
dass man sich da im Team drauf einigt, weil wenn jetzt der eine
30:41
die Klammer in ne neue Zeile packt und der andere hinter die
30:44
Hüftbedingungen, dann ist das halt einfach wieder nicht
30:46
konsistent und das schadet dem gesamten Projekt und der
30:49
Software. Und ja, ich bin der Meinung,
30:51
dass Fordertierung so einen großen Impact haben kann, weil
30:55
allein wenn du nur jedes Mal darüber diskutierst im Team.
30:58
Ne lass so machen, ne lass so machen, verbrennst du ja auch
31:01
schon Zeit, das ist ja schon mal so der erste Punkt dabei, ne.
31:04
Und der zweite Punkt ist auch, zum Beispiel wenn du.
31:08
Einen Commit machst und guckst, wie viele Changes da sind, das
31:11
finde ich ist absolut nicht zu vernachlässigen und du guckst
31:14
dir wirklich, weil man sollte natürlich davon ausgehen, dass
31:17
wenn ein Code Review gemacht wird, dass man, dass es mit
31:19
Sorgfalt gemacht wird und dann guckst du dir jede Zeile, die
31:22
sich geändert hat an und wenn dann aber super viel.
31:25
Ich sag jetzt mal. Change Müll dabei ist.
31:30
Wo formatierungsbedingt? Genau, wo du halt einfach.
31:33
Du denkst, OK, ich guck mir das jetzt an und dann ist es aber
31:36
eigentlich. Quatsch, dass sich das wirklich
31:39
anzugucken. Und dann wirst du vielleicht
31:40
unaufmerksam und verlierst vielleicht ne Zeile aus den
31:43
Augen, die tatsächlich wichtig ist zum Reviewen dann ist halt
31:47
blöd und das ist. Finde ich auch n nicht zu
31:49
vernachlässigender Punkt, der durchaus ins Gewicht fallen
31:53
kann. Ja, absolut.
31:58
Bin ich ganz bei dir, dann ist halt natürlich die Frage, wie
32:01
die IDS eingestellt sind ne, weil wenn du jetzt zum Beispiel
32:03
deine Autoformatierung unterschiedlich dann wieder
32:05
einstellst wie in deinem Beispiel, dann wirst du ja
32:07
zwangsläufig, weil ganz ehrlich ist bei mir so automatisiert,
32:11
dass ich Code schreibe und danach den Shortcut für die
32:13
Autoformatierung Reinhaue, also so wirklich richtig
32:16
munterbewusstsein, das heißt ich würde ständig diese Changes
32:19
erzeugen, richtig, und das ist natürlich super nervig.
32:22
Dann habe ich ganz bei dir. Einen Punkt hätte ich noch.
32:28
Es hat dann doch wieder eine längere Folge gewonnen, auch
32:30
wenn es nur in Anführungszeichen um Formatierung geht.
32:33
Ich bin gespannt, es ist natürlich nicht nur.
32:38
Dass man im Team sich auf eine Formatierung einigt, die ja
32:42
hoffentlich sinnvoll ist und nicht einfach sagt okay wir
32:44
machen jetzt eine richtig sinnlose Formatierung, aber wir
32:47
committen uns im Team da darauf und alle halten sich verdammt
32:50
noch mal da dran. Ich greife noch mal diesen Punkt
32:54
auf, den du meintest. Diese Voreinstellung, von der
32:56
IDI ja schon meistens sehr souverän ist und ausreichend.
33:01
Es gibt ja auch Sprachenbedingt gewisse Coding Guidelines, also
33:08
Standardisierung. Sprachenabhängig das heißt, du
33:11
weißt jetzt zum Beispiel, OK, unser Projekt wird in Python
33:14
entwickelt, da gibt es einfach n Coding Standard für wie Python
33:17
Code so Best Practice mäßig auszusehen hat und der kann sich
33:21
natürlich auch wiederum unterscheiden von zum Beispiel
33:24
Java Code. Oder noch besser, weil Python ja
33:27
wie gesagt keine Klammern und mit Einrückung ist, sag ich mal
33:31
notwendig. Sagen wir doch mal zum Beispiel,
33:32
dass es ne unterschiedliche Coding Guidelines gibt von Java
33:35
und zum Beispiel C Sharp. Ne mit den Klammer.
33:39
Einrückung und so weiter. Ne, genau was wir jetzt ja auch
33:42
hatten als Thema und ich finde das ist halt auch immer n
33:44
wichtiger Punkt, wenn diese Sprache oder durch die
33:47
Entwickler durch die Community Guidelines existieren, dann
33:52
sollte man sich auch daran halten und nicht sowas wie.
33:57
Beispielsweise was das Cap ist, glaube ich.
33:59
Pascal Case wichtig. Bei den Namen komme ich immer
34:02
durcheinander, das heißt ich glaube Funktionsnamen fangen
34:07
immer mit einem großen Buchstaben an, das ist der
34:09
Unterschied zum Camel Case, was bei Java glaube ich dann die
34:12
Guideline ist, dass du da sagst okay ein Funktionsname fängt
34:16
immer mit Kleinbuchstaben an und dann wortgetrennt immer wieder
34:19
der erste Buchstabe groß, da sind sie dann gleich, aber wie
34:22
gesagt C auch der erste Buchstabe Groß Java der erste
34:26
Buchstabe Klein. Da gibt es, glaube ich bei C
34:29
auch noch so Ausnahmen beziehungsweise eine
34:32
Unterscheidung, ob es eine Klassen Name ist.
34:34
Funktionsname Variablenname will ich jetzt nicht weiter drauf
34:37
eingehen, weil wir auch einfach keine Sicherheit Entwickler
34:39
sind. Ist das irgendwas falsches
34:40
sagen? Aber da siehst du es ja schon
34:44
und es macht ja eigentlich wenig Sinn, wenn ich dann C Sharp
34:46
Projekt habe und aus der Java Welt komme und sage NÖ Camel
34:50
Case für immer, ich werde jetzt alles so benennen weil ich mein
34:54
was hat das was bringt dir das jetzt kommt im Team.
34:57
Also ihr, man braucht mehr Entwickler.
34:59
Die Firma stellt noch einen Entwickler für genau dieses
35:01
Projekt ein. N absoluter.
35:05
Fachmann in Sachen C. Kommt in dieses.
35:08
Projekt und man hat gesagt, ja ist alles Camel Case und der
35:11
denkt sich so. Schönes t Shirt Projekt was ihr
35:13
habt so richtig schön gegen diese standardisierten
35:17
Guidelines. Warum zur Hölle ich mein?
35:20
Er kann natürlich sagen, OK, wir einigen uns auf Camel Case, mach
35:22
ich, aber es ist ja komplett gegen seine Erfahrungen dann in
35:25
dem Moment und deswegen finde ich.
35:27
Wenn eine Sprache gewisse Guidelines hat, haltet er also
35:31
hält man sich auch da dran oder? Also oder wie siehst.
35:33
Du das ja, na definitiv. Also im Endeffekt ist es ja so,
35:36
dass man sich natürlich auch im Endeffekt genauso die Erwartung
35:39
an sich selber setzen kann. Also angenommen du schreibst.
35:43
Code jemand kommt rein und sagt. Was ist was hast n du hier
35:48
gemacht? So nach dem Motto Ne und wenn es
35:49
jetzt nur um die Eigenheiten dieser Sprache geht, wie du das
35:53
gerade so schön beschrieben hast, dann ist es ja trotzdem
35:56
blöd, weil es ja nun wirklich an sich auch keine schwere Sache
36:00
ist, das zu machen so, obwohl ich sagen muss, dass auch wenn
36:04
man jetzt zum Beispiel mal in Python programmiert, finde ich
36:07
es tatsächlich geht es sehr gegen meinen natürlichen
36:11
Schreibstil, sozusagen in dem Fall, ich glaube, das heißt
36:15
snaycase Ich bin mir gerade auch nicht sicher.
36:18
Wörter mit unterstrich zu trennen, das ist ja so ne Python
36:21
Richtlinie ne, weil wir ja gerade auch von Camble Case zum
36:24
Beispiel gesprochen haben und. Es wirklich.
36:28
Es widerstrebt mir, weil immer diesen unterstrich zu zu
36:33
schreiben find ich find ich wirklich schwierig oder
36:35
anstrengend oder ungewohnt ne ungewohnt ist glaub ich das
36:38
beste. Passt am besten, aber es ist
36:42
halt schwierig, aber trotzdem denk ich mir so ja OK, es gibt
36:45
bestimmte Guidelines und wenn die in Python nun mal so sind,
36:48
dann möcht ich mich ja auch daran halten, wenn ich in Python
36:50
Code ne. Also es gibt ja auch keine
36:54
Ahnung. Ich gehe auch nicht zu dir nach
36:55
Hause und wenn du sagst, so, ja gut, ich möchte aber gerne
36:58
bitte, dass zu Hause keine Schuhe getragen werden und ich
37:01
latsch die ganze Zeit mit Schuhen in deiner Wohnung rum,
37:03
weiß ich nicht, dann ist das. Irgendwie.
37:05
Die ziehst immer schön aus, Freundchen.
37:09
Das mache ich nicht. Ich will meine Schuhe am alten,
37:14
aber das ist halt so. Weißt du dann.
37:17
Dann denke ich mir so, es gehört doch einfach zum guten Ton, dann
37:19
auch wirklich zu sagen, ja gut, pass auf, wir sind in dieser
37:22
Welt, also nutzen wir halt auch die das Reglement sag ich jetzt
37:26
mal von dieser Welt. Arbeiten halt einfach damit und
37:31
das wirkt ja auch einfach professioneller.
37:33
Also wenn man jetzt zum Beispiel sagt, ja, ich möchte gerne ne,
37:35
also ich Fabian möchte gerne ein professioneller
37:37
Softwareentwickler sein oder vielleicht noch werden, wer weiß
37:41
das schon. Ist auf gutem Weg.
37:43
Danke. Danke.
37:46
Dann dann, dann ist es ja auch einfach, dann gehört es dazu,
37:49
sich auch daran zu halten, finde ich.
37:53
Und es ist halt wie gesagt auch nicht so schwer.
37:55
Ne und deswegen? Ja, aus maximal die Hürde, so
38:01
diese innere. Dieser innere Widerstand zu
38:04
sagen, Hey, ich find das nicht cool.
38:07
Das ist ja eigentlich so die genau, obwohl ich halt zum
38:09
Beispiel auch sagen muss, dass wenn ich irgendwas Code in
38:11
Python beispielsweise und ich denk mir so, ja, ich find
38:14
eigentlich camel case macht, mir find ich einfach besser lesbar,
38:17
sieht schöner aus, trotzdem wenn ich das irgendwas in mir in mein
38:22
innerer Monk sagt, du bist gerade in Python und es gefällt
38:25
dir nicht, aber du nutzt die Unterstriche ja, so ist es auch.
38:29
Ist bei mir genauso und dann ärgert man sich so, wenn man es
38:32
vergessen hat. Jetzt muss ich wieder alles
38:34
umbenennen hier refectern, weil ich mich da nicht dran gehalten
38:37
habe, das nervt aber. Im Endeffekt möchte man es ja
38:40
auch so machen und da sind wir auch wieder bei diesen ganzen
38:42
Punkten, die wir jetzt hatten. Es ist wahrscheinlich auch im
38:45
Team so kommuniziert, es ist der Standard der Sprache, also hält
38:48
man sich auch daran, weil das Ganze fördert dann am Ende auch
38:51
oder sorgt für eine super Formatierung und steigert auch
38:55
die Produktivität im gesamten Team.
38:58
Aber das ist einfach Fakt in meinen Augen.
39:00
Genau, und sowas kann man auch alleine gut üben, weil klar, es
39:05
sind immer Sachen im Team und auch wenn man damit anfängt und
39:07
noch nicht im Team arbeitet, es sind Low hanging fruits.
39:11
Man sollte sich auch damit auseinandersetzen, nicht einfach
39:13
irgendwie machen, wie man es gerne möchte, sondern vielleicht
39:16
auch für sich selber mal evaluieren, was macht denn zum
39:19
Beispiel Sinn, weil es kommt irgendwann genau an diesem
39:21
Punkt, dass zum Beispiel das genau solche Teamentscheidungen
39:24
getroffen werden und man. Vielleicht.
39:26
Dann sagt ja gut, ich würde das aber wahrscheinlich so machen.
39:29
Und wenn dann jemand sagt, Na ja, warum würdest du so machen
39:31
und du sagst keine Ahnung, dann ist blöd ne.
39:34
Also man hat natürlich dann irgendwie schon, man sollte sich
39:38
da am Anfang vielleicht auch mal n bisschen ausprobieren um zu
39:40
sagen, OK was gefällt mir gut welche.
39:43
Sage ich jetzt mal. Guidelines gibt es für die und
39:44
die Sprache und dann kann man quasi sagen okay ich, ich
39:48
arbeite in diesen Guidelines, ich halte mich an die Guidelines
39:52
dieser Sprache und in den Grenzen sozusagen der
39:55
Variabilität, was man halt ebenso selber ausprobieren kann,
39:58
da guckt man halt was für einen besser am besten geeignet ist,
40:01
weil im Endeffekt, wenn man irgendwann, sage ich mal, in
40:04
einem Team in den Austausch kommt und genau darüber redet,
40:07
dann kann man ja vielleicht auch sagen, du Pass auf aus den und
40:10
den Gründen mache ich das so und so, und vielleicht denkt sich
40:13
jemand anders, da stimmt das voll, die gute Idee.
40:16
Habe ich noch gar nicht dran gedacht.
40:17
Machen wir. So, oder du lässt dich.
40:19
Überzeugen also. Es gibt unterschiedliche Sachen,
40:21
deswegen ist es halt auch, wenn man damit anfängt auch
40:25
interessant sich damit auseinander zu setzen.
40:28
Ja, absolut. Und da ist halt dann wirklich
40:29
der Punkt, dass man auf einen Nenner kommt und alle sich daran
40:33
halten und damit auch glücklich sind, quasi so kurz entwickeln.
40:36
Ich finde man kann ja auch jetzt zum zum Abschluss der Folge
40:40
würde ich noch ne kleine Analogie bringen dazu.
40:43
Und zwar sagen wir ja immer. Es geht darum, den Code gut
40:48
lesen zu können. So, jetzt denkt sich vielleicht
40:51
der eine oder andere ja, hm lesen ja OK, aber du musst ja
40:55
wirklich, wenn du den Code verstehen möchtest.
40:57
Wenn du jetzt über das guckst, was jemand anderes programmiert
40:59
hast, dann liest du ja wirklich über den Code und nehmen wir
41:03
doch mal die Analogie, wirklich ein Buch lesen und jetzt sitzt
41:07
man da, schlägt das Buch auf, man liest, man liest die ersten
41:10
Seiten, es läuft, es fließt, man hat einen richtig guten
41:14
Lesefluss, so und auf Seite 5 geht es auf einmal los.
41:18
Dass irgendwelche random Absätze drin sind, eine ganz andere
41:20
Formatierung des Textes. So auf einmal hast du
41:23
Unterkapitel, die gab es vorher nicht, irgendwelche Random
41:26
Überschriften da drin denkst du so okay das ist eine andere
41:29
Schriftart, die Schriftgröße hat sich geändert, was auch immer
41:32
der Text ist ein. Dreieck man liest von rechts
41:34
nach links und von links nach rechts.
41:36
Ja, also vielleicht doch nicht mal so wild, aber einfach nur
41:39
die Schriftart hat sich geändert.
41:40
Die Größe hat sich geändert, die Formatierung, du kannst es zwar
41:43
immer noch von links nach rechts, von oben nach unten,
41:45
also ich gehe jetzt von einem deutsch geschriebenen Buch aus.
41:49
Du kannst es eigentlich genauso weiterlesen wie vorher, aber
41:52
jetzt soll mir mal einer sagen, das wird seinen Lesefluss nicht
41:55
beeinflussen. Das wird mein Lesefluss.
41:59
Nicht beeinflussen, OK. Taubt die Welt da gilt oder wie
42:01
war das früher immer? Nein, das werden wir prüfen.
42:05
Ich verstehe was du, was du, was du damit sagen willst.
42:07
Und das ist ne sehr sehr schöne Analogie.
42:10
Danke dafür. Das ist ja also, das kann man
42:13
sich auf jeden Fall mal durch den Kopf gehen lassen, finde ich
42:16
gut. Danke dafür für dieses Beispiel,
42:19
das. Find ich sehr sehr gut.
42:21
Da muss man natürlich sagen, Schriftart und Schriftgröße
42:24
spielt beim Code genauso. Ne Rolle, das stimmt.
42:27
Sollte auch einheitlich sein. Genau, ja, auf jeden Fall würde
42:31
ich sagen, haben wir das ganze Thema doch mal entspannt
42:35
auseinandergenommen und wieder zusammengesetzt.
42:39
Und ja, damit würde ich sagen, Tino, Dankeschön fürs Gespräch
42:43
für diese, den interessanten Austausch über ein zwar sehr
42:48
triviales oder langweiliges Thema eventuell, aber ich fand
42:52
es auf dem. Ersten Schein.
42:54
Auf den ersten Schein genau, man kann mehr darüber
42:56
philosophieren, als man vielleicht am Anfang denkt.
42:59
Deswegen danke für den Austausch und.
43:02
Ja, bitte, bitte hat Spaß gemacht.
43:03
Auf jeden Fall. Und in diesem Sinne würde ich
43:06
sagen, schließen wir die Folge ab, liebe Zuhörerin oder lieber
43:09
Zuhörer? Wie wir es schon mal gesagt
43:12
haben, schreibt uns doch auch mal was so.
43:14
Eure Coding Guidelines sind, was ihr vielleicht für interessante
43:19
Merkwürdigkeiten mittlerweile mitgekriegt habt, gelesen habt n
43:24
Code, was sehr sehr merkwürdig vielleicht war.
43:28
Gute Practices, die ihr rausgefunden habt, schreibt sie
43:31
uns über die Podcast Mail, gerne auch bei Instagram.
43:34
Wie ihr lustig seid die Links zu allen unseren Plattformen ist in
43:38
den Shownotes. Und ich würde einfach nochmal
43:42
gerne. An euch appellieren, wenn euch
43:45
diese Folge gefallen hat, dann empfiehlt sie doch einfach mal 2
43:49
euren Freunden, Arbeitskollegen, Kolleginnen.
43:52
Gibt einfach mal weiter und ansonsten würde ich sagen, hören
43:55
wir uns alle in der nächsten Folge wieder und in diesem Sinne
43:59
noch einen schönen Tag eure Coding Buddies.
44:01
Gemeinsam. Was?