Sehr gutes Video! Interessante Alternative zu den switch-case statements im letzten Beispiel wären übrigens die in Java12 (finalisiert in Java14) neu eingeführten switch expressions: String message = switch (ziffer) { case 0 -> "Null"; case 1 -> "Eins"; case 2 -> "Zwei"; case 3 -> "Drei"; ... } System.out.println(message);
Klasse! Und falls man nicht alles auf Anhieb ändern kann: Lernen ist manchmal ein etwas langwieriger Prozess (vor allem, wenn man bestimmte Coding Hobbits schob seit Anbeginn seiner Karriere hat).
Gutes Video! Das Ganze ist übrigens allgemein unter dem Namen "Guard Clauses" bekannt, zuerst veröffentlicht von Martin Fowler: refactoring.com/catalog/replaceNestedConditionalWithGuardClauses.html
Hi, ich wollte dich informieren dass ich immer noch deine nicen Vids schaue, vor kurzem hies ich auf ytb noch irgendwas mit esport oder so... auf jeden fall habe ich jetzt einen geilen club gefunden und lerne jetzt richtig programmieren ((((((((:::::::::::::....
Sehr schön. Sehr richtig. Den allseits beliebten Ternary "return x ? true : false;" (statt "return x;") hast du zwar nur indirekt (in if-Form) angesprochen, aber egal. Dass "return Ausdruck;" schneller sein kann als als "if (Ausdruck) return true else return false;" hast du verschwiegen, aber das ist inzwischen ja fast egal - solange der Compiler den Nutzer unterstützt und das nachoptimiert, um Lücken in der Pipeline zu vermeiden. Durch Java hast du wahrscheinlich den Missbrauch von switches vermieden. Ich hatte da neulich ein Gespräch mit nem Neuling über ungefähr sowas: switch (true) { case v == "a": .... break; case t == 1: ... break; }
Statt Switch-Case kann man in vielen Fällen auch eine Map einsetzen. In vielen Sprachen ist das Switch Case Statement sehr stark beschränkt, da ist ein Map Datentyp eine gute und effiziente Alternative und oft ist es auch übersichtlicher, da man zum Beispiel die breaks einspart. Hängt aber letztlich vom konkreten Anwendungsfall an, was besser ist.
Ganz genau so wie ab 3:25 ! Dazu gibt es von Brian Kernighan ein Buch "Elements of Programming Style" und eine Vorlesung als Video. In diesem zeigt er mit vielen Beispielen wie man guten Code schreibt und wie nicht. Unter anderem wird da auch genau das behandelt wie hier im Video. th-cam.com/video/8SUkrR7ZfTA/w-d-xo.html&feature=share
@3:23 - Ich bin auch ein Fan von Short-Circuit exits (return) geworden. Unter VB6 hat man immer am Ende einer Function den Return-Value gesetzt (weil die syntax eine Zuweisung über den Function-Name wollte) - oder man hat einen Default-Wert am Anfang der Function gesetzt, dann konnte man auch mit EXIT FUNCTION raus. Daher neige ich immer noch dazu, Short-Circuit RETURNs im CODE mit Kommentar dahinter zu kennzeichnen ; )
Meiner Meinung fehlt da noch ein ganz wichtiger Tipp, oft lässt sich ein Switch-Case (egal ob als If oder Switch-Case geschrieben) mit eine Generalisierung (Vererbung) vermeiden Ist meiner Erfahrung nach meistens die bessere Wahl
Eine weitere Möglichkeit If-Abfragen zu vermeiden ist zum Beispiel die Verwendung von Sealed Classes mit when. Finde das bei Kotlin extrem cool: kotlinlang.org/docs/sealed-classes.html#try-sealed-interfaces-and-package-wide-hierarchies-of-sealed-classes
@@Florian.Dalwigk Das ist eigentlich immer der Fall wenn man je nach Typ einen anderen Code ausführt. Der Artikel enthält ein ganz gutes Beispiel: refactoring.guru/replace-conditional-with-polymorphism
Moin moin, erstmal geiles Video, dass es unter deutschsprachigen Programmierern sowas wie Clean Code gibt wusste ich gar nicht, das scheint im engischen Raum schon ziemlich "verbreiteterer" zu sein. Dafür schon einmal Kudos. Zu Switch-Case-Anweisungen ist zu beachten, dass diese auch nur einfachere If-Anweisungen sind. Klar kann man das ganze auch Overengineeren, aber ich habe selbst festgestellt, dass nach nen paar Wochen und Monaten einen ein Switch-Case ziemlich in den Arsch beißen kann, vor allem wenn er in einem Modul steckt, welches von woanders benutzt wird. Einfach, wie hier mag das noch gehen, wird aber ziemlich schnell unübersichtlich. Ich schreibe mir dafür dann einfach eine Klasse mit der entsprechenden Klassenfunktion und behandle darin alle Fälle, so muss ich dann nicht alle Switch-Cases durcharbeiten wenn sich etwas ändert. In diesem Fall steht dem natürlich nichts im Weg, aber ich meine hinten raus. Wenn man etwas komplexer geworden ist. MfG
Das witzige ist, dass z.T. der Java Code vom Compiler automatisch nach deiner Regel "Error handling first" umgebaut wird. Ist mir letztens aufgefallen, als IDEA eine Klasse einer unserer internen Libraries decompiliert hat.
Kurze Frage zu dem Erklärten Beispiel bei 3:50, müsste man das upload_to_server() nicht in den else teil beim 2. If block einfügen? Weil sonst würde der doch einfach trotzdem uploaden oder?
@@GradientTim In dem Fall, wovon man selten ausgehen sollte, macht eine Überprüfung auf null sowieso nie Sinn. Das wäre ja dann das gleiche wie ein if(true) bzw. if(false)
Ich habe bisher immer nach dem Motto "Fehlerbehebung hat Vorrang" mit If-Anweisungen gearbeitet. Mein Freund mit dem ich öfter programmiere macht das nicht, das triggerd mich immer xD
Ich mach das auch, erst alles prüfen und return / throw. Ich hab fast keine else und fast jedes if hat ein return, ich nutze viel continue und break... Kollegen die das lesen bekommen sofort mit was die Methode nicht macht. Das enttäuscht falsche Erwartungen. Nach meinem Gefühl sind falsche Annahmen die größte Quelle von schwer zu entdeckenden Fehlern.
oder Sie können assoziative Maps wie folgt verwenden anstatt switch statement (Bespiel im Lua): local map = { ["A"] = 10, ["B"] = 20, .... }; local input = "Hallo"; local output = map["Hallo"]; if(output == nil) then print("Fehler: ungültige eingabe"); return; end
"Schalteranweisung" ... :D . Hatte damals an der Uni einen (ziemlich alten) Prof, der immer "Kellerspeicher" gesagt hat, wenn er stack meinte. Hat ne Weile gebraucht, bis das alle Studis das gerafft hatten ...
Ist bei 3:55 die if nicht: if (!file.isMP3() || ! file.isPDF()) Sonst breche ich doch ab, wenn die Datei keine MP3 und keine PDF ist, das geht aber ja nicht, denn sie ist entweder MP3 oder PDF. Oder sitz ich gerade auf dem Schlauch?
Negationen lesen sich immer recht schwer. Also möglichst immer die positiv form verwenden wenn irgendwie möglich. If allowedFileTypes.Contains(...) then Upload to server ... oder if (mp3 || pdf) then Upload to server
Clean code ist ein wichtiger Ansatz. Aber gleichzeitig die Konventionen nicht einzuhalten finde ich dann schon recht unschön. Funktionen schreibt man in camel case und für gewöhnlich in Englisch. Eine Funktion die ein boolean zurück gibt beginnt mit "is". Besser als mit != null zu vergleichen ist den konkreten Typ zu wählen, was in der regel === undefined ist.
"Sie sind aus der Programmierung nicht mehr wegzudenken und tauchen an vielen Stellen auf" Ja, Programmierung ist ein wundervolles Abenteuer. Das erinnert mich an die Zeit, als ich auf dem C 64 die Programmiersprache "C" gelernt habe und total stolz darauf war, das Prinzip von Funktionen verstanden zu haben und auch schon verschachtelte Funktionsaufrufe genutzt habe. Da habe ich mir zur Belohnung auch immer Marshmallows geröstet... Ich hab ja bis dahin nur in Assembler programmiert und dort habe ich das, was Compiler und Linker tun, alles selber machen müssen. (wir hatten ja nichts) Ach, was würde ich mir wünschen, würden die zwei ersten Semester Informatik daraus bestehen, einfache Funktionen wie Multiplikation und Division von Zahlen, die nicht in die CPU-Architektur passen, schreiben zu müssen - also z.B. 128 Bit lange Zahlen auf einer 8-Bit Architektur! Man braucht nämlich auch heutzutage noch Kalkulationen mit Zahlen, die länger sind als 64 Bit - Weitaus länger! (RSA, Diffie Hellmann, Myer's Bit-Vector Algorythmus, u.v.a.) Zum Ende des zweiten Semesters müsste die abschließende Prüfung daraus bestehen, die RSA Verschlüsselung oder den Diffie-Hellmann Schlüsselaustausch, den Huffmann- oder Arithmetischen Kompessor für eine Z80 CPU in Assembler zu programmieren. Wer das übersteht, weiß wie Computer funktionieren und nur die sollen weitermachen dürfen! Der Rest kann ja immer noch Chemie, BWL oder Hauswirtschaft studieren... Ich möchte mal ein "Clean Code" Video sehen, daß für PostScript gemacht wurde :-D :-D :-D
Der letzte Fall ist ja nur stellvertretend für Dinge, die Wirklich einen Switch benötigen - z.B. wenn man keine fortlaufenden Zahlen hat, sondern mal eine 1, eine 2 und die 255... Den gezeigten Fall hätte ich mit einer Liste/Array gelöst. Eine weitere Möglichkeit, wenn man eine vollständige (oder Lückenfreie) Liste hat und anhand derer unterschiedlichen nicht-trivialen Code ausführen möchte, wären Funktionspointer in einer Liste oder anonyme Funktionen - wie auch immer die in den unterschiedlichen Sprachen genannt werden. Ich kann gerade fühlen, wie einige Leute nun zu weinen anfangen, weil eben diese Methoden nicht mehr ganz so leicht zu lesenden Code erzeugen. Aber wenn für Euer Programm folgendes Soran-Zitat aus "Star Trek: Treffen der Generationen" zutrifft "die zeit ist das feuer in dem wir verbrennen", werden Knaben zu Männern und Clean-Code wird zu einem Hindernis, Eure Ziele zu erreichen!
Man sollte noch erwähne dass lokale result Variablen die in diesem verschachtelten branches gesetzt werden (oder initial null wenn kein Fall zutrifft) das ganze noch verschlimmern und öfters mal zu null Rückgabe und dann nullpointerexceötkons. Führen. We nn man auf null Rückgaben nicht verzichten will, dann wenigstens in allen guards explizit „return null;“ schreiben, und nicht „Objekt result = null; if(guard()) return result;} In den Fall hilft es auch Variablen generell nicht auf null zu initialisieren wen man davon ausgeht alle Fälle in if/else abzudecken.
sehr schönes Video .. meist kommen die Anforderungen im echten Entwickler-Leben aber zeitversetzt, dh. man hat eine if-Anweisung und muß weitere voneinander abhängige Bedingungen einbauen ohne dabei bestehenden funktionieren Code zu gefährden (da auch niemand da ist der die Änderungen am Ende testet *g) .. dh. man geht auf Nummer sicher (und nicht nach Schönheit des Codes) um den Produktiv-Betrieb nicht zu gefährden ... dann entsteht zwangsläufig "historisch gewachsener verschachtelter" Code .. den man aber nach 3-4 Jahren noch lesen kann wenn wenn man sich ein paar Kommentare dazu schreibt
Tolles Video, aber mit dem Switch bin ich nicht einverstanden. In Clean Code sollte man auf Switch cases verzichten. Switch cases machen den den Code u.u. extrem unlesbar. Zusätzlich widersprechen sie, dem Prinzip, dass jede Methode nur eine Aufgabe haben darf. Mein Tipp Switch cases durch Dictionary ablösen. Wesentlich sauberer und verständlicher. Vor allem wenn man durch Schnittstellen entkoppelt.
Was ich mir eigentlich darunter vorstelle, wenn es um Clean Code und if-Anweisungen geht: if-Anweisungen so weit es geht durch polymorphe Methodenaufrufe ersetzen. Und if-Anweisungen hauptsächlich in Factories benutzen, um zu entscheiden, welche polymorphe Implementierung erzeugt werden soll. Resultat: Komplexe if-Anweisungen verschwinden von ganz allein und verteilen sich auf unterschiedlich ausgeprägte Unterklassen. Zudem wird das Open-Closed-Prinzip gefördert 🔥 (vgl. Martin, 2009: Clean Code, S. 299)
Gar nicht provokant, sondern genau richtig. In meinem Job tue ich genau das: ich versuche, if so oft es geht zu vermeiden und else benutze ich nie. Sehr viele if(-else) Anweisungen existieren nur, weil der Programmierer keine neue Klasse erstellen wollte, obwohl das die bessere Option gewesen wäre. Es gibt dazu hier auf YT einen weunderbaren Vortrag von Sandi Metz ("all the little things"), in der sie das "Gilded Rose" Kata bespricht. Amfang des Vortrages steht eine if-else-Hölle, die keiner mehr durchblickt, am Ende stehen viele kleine Objekte und leicht verständlicher code, der sich einfach um neue Funktionalität erweitern lässt.
@@Florian.Dalwigk Der hier ist es: th-cam.com/video/8bZh5LMaSmE/w-d-xo.html "Nothing is something" geht in bisschen in die gleiche Richtung (gegen if/else), behandelt aber einen anderen Fall, der für viele if/else im code sorgen kann: th-cam.com/video/OMPfEXIlTVE/w-d-xo.html
Das letzte Beispiel gehört auf jeden Fall mit einer Mapping-Tabelle (z.B. assoziatives Array, dictionary) gemacht, bitte weder if noch switch für sowas...
Leider wird (bei uns zumindest) auch heute noch auf der MISRA Regel "Nur ein return statement am Ende einer jeden Funktion" herumgeritten. Ich kann den Sinn dieser veralteteten Regel in der heutigen Zeit einfach nicht mehr erkennen und bin ebenso deiner Meinung, dass der Code so besser zu lesen ist. Selbst mit einer lokalen Variable für einen return code entstehen redundante Codezeilen die für den Betrachter unnötig sind.
"If anwesungen sind aus der Programmierung nicht mehr wegzudenken" ich glaub mein Hirn schimmelt. If Anweisung sind die Definition von Digitaltechnik. Jeder transistor ist eine if Anweisung. Programme funktionieren nur wegen if Anwesungen. Ohne conditional jump ist eine maschiene nicht Turing komplett. Du hättest diesen Satz über jedes Andere feature sagen können, nur nicht über if Anweisungen...
@@hansdietrich83 Naja, ganz so ists auch nicht, man kann Verzweigungen auch per switch case umsetzen, wie im Video gezeigt, per pattern matching oder if expressions, ternärem operator usw... chill mal
Eigentlich ganz gutes Video. Aber Switch Case würde ich keinem mehr empfehlen. Das ist ein Relikt, das es zu vermeiden gilt (gerade das unschöne explizite break; welches erforderlich ist und der implizite Fallthrough macht switch case ziemlich hässlich). Besser auf ein Mapping zurückgreifen.
@@Florian.Dalwigk alles gut : ) deine videos sind sehr gut und hochwertig man lernt echt was Eine Frage hast du dieses eine Hacker Mythen Cybersicherheit wegen den ganzen anderen Vorfaellen runtergenommen?
Ein weiterer Tipp: Wenn man sicherstellen kann, dass die Funktion immer mit validen Argumenten aufgerufen wird, kann man die Fehlerbehandlung weglassen 😉 Hört sich erstmal super banal an, aber die die mehr Erfahrung haben, wissen wovon ich rede 😂 Log-and-Throw Pattern at it's best 🙃
Sehr gutes Video! Werd diese Tips auf jeden Fall mal ausprobieren. Bitte mehr zu Clean Codes.
Ausgezeichnet!
Bitte mehr zum Thema Clean Code sehr schön veranschaulicht
Danke!
Hahaha NEIN FLORIAN
Sehr gutes Video! Interessante Alternative zu den switch-case statements im letzten Beispiel wären übrigens die in Java12 (finalisiert in Java14) neu eingeführten switch expressions:
String message = switch (ziffer) {
case 0 -> "Null";
case 1 -> "Eins";
case 2 -> "Zwei";
case 3 -> "Drei";
...
}
System.out.println(message);
Ui, die kannte ich noch gar nicht! Da mache ich vlt mal ein Video zu!
Dürfte ich deinen Kommentar dann ggf. im Video zeigen? Ich weiß aber noch nicht, ob und wann ich dazu ein Video mache.
@@Florian.Dalwigk klar, kein Problem!👍
Super! Danke :)
Sehr nices Video! Die Dinge hab ich tatsächlich auch schon bei mir erkannt und verändert!
Klasse! Und falls man nicht alles auf Anhieb ändern kann: Lernen ist manchmal ein etwas langwieriger Prozess (vor allem, wenn man bestimmte Coding Hobbits schob seit Anbeginn seiner Karriere hat).
Gutes Video! Das Ganze ist übrigens allgemein unter dem Namen "Guard Clauses" bekannt, zuerst veröffentlicht von Martin Fowler:
refactoring.com/catalog/replaceNestedConditionalWithGuardClauses.html
Hi, ich wollte dich informieren dass ich immer noch deine nicen Vids schaue, vor kurzem hies ich auf ytb noch irgendwas mit esport oder so...
auf jeden fall habe ich jetzt einen geilen club gefunden und lerne jetzt richtig programmieren ((((((((:::::::::::::....
Es freut mich, dass du noch an Bord bist :)
Sehr schön! Was lernst du dort für eine Programmiersprache?
Haha extra gewartet, um den tausendsten Like auf dieses Video zu geben 😏👍 übrigens ein gutes Video
Nice, vielen Dank 😎
Sehr schön. Sehr richtig.
Den allseits beliebten Ternary "return x ? true : false;" (statt "return x;") hast du zwar nur indirekt (in if-Form) angesprochen, aber egal.
Dass "return Ausdruck;" schneller sein kann als als "if (Ausdruck) return true else return false;" hast du verschwiegen, aber das ist inzwischen ja fast egal - solange der Compiler den Nutzer unterstützt und das nachoptimiert, um Lücken in der Pipeline zu vermeiden.
Durch Java hast du wahrscheinlich den Missbrauch von switches vermieden. Ich hatte da neulich ein Gespräch mit nem Neuling über ungefähr sowas:
switch (true) {
case v == "a": .... break;
case t == 1: ... break;
}
Stimmbruch ist on fleek
Da sollte ich eigentlich schon längst draußen sein :D
@@Florian.Dalwigk xD
Statt Switch-Case kann man in vielen Fällen auch eine Map einsetzen. In vielen Sprachen ist das Switch Case Statement sehr stark beschränkt, da ist ein Map Datentyp eine gute und effiziente Alternative und oft ist es auch übersichtlicher, da man zum Beispiel die breaks einspart. Hängt aber letztlich vom konkreten Anwendungsfall an, was besser ist.
Gute Alternative!
Maps sind halt vergleichsweise langsam und vom compiler nicht optimierbar.
Mehr clean code Videos wären super!! :D
Ich überlege mir, ob ich da wirklich noch ein paar Teile zu drehe :)
Ganz genau so wie ab 3:25 ! Dazu gibt es von Brian Kernighan ein Buch "Elements of Programming Style" und eine Vorlesung als Video. In diesem zeigt er mit vielen Beispielen wie man guten Code schreibt und wie nicht. Unter anderem wird da auch genau das behandelt wie hier im Video.
th-cam.com/video/8SUkrR7ZfTA/w-d-xo.html&feature=share
Danke für die Enpfehlung! Das werde ich mir mal anschauen. :)
@3:23 - Ich bin auch ein Fan von Short-Circuit exits (return) geworden. Unter VB6 hat man immer am Ende einer Function den Return-Value gesetzt (weil die syntax eine Zuweisung über den Function-Name wollte) - oder man hat einen Default-Wert am Anfang der Function gesetzt, dann konnte man auch mit EXIT FUNCTION raus. Daher neige ich immer noch dazu, Short-Circuit RETURNs im CODE mit Kommentar dahinter zu kennzeichnen ; )
Hihi :)
Meiner Meinung fehlt da noch ein ganz wichtiger Tipp, oft lässt sich ein Switch-Case (egal ob als If oder Switch-Case geschrieben) mit eine Generalisierung (Vererbung) vermeiden
Ist meiner Erfahrung nach meistens die bessere Wahl
Hättest du da mal ein konkretes Beispiel?
Eine weitere Möglichkeit If-Abfragen zu vermeiden ist zum Beispiel die Verwendung von Sealed Classes mit when. Finde das bei Kotlin extrem cool: kotlinlang.org/docs/sealed-classes.html#try-sealed-interfaces-and-package-wide-hierarchies-of-sealed-classes
@@Florian.Dalwigk
Das ist eigentlich immer der Fall wenn man je nach Typ einen anderen Code ausführt. Der Artikel enthält ein ganz gutes Beispiel:
refactoring.guru/replace-conditional-with-polymorphism
@@jakobseitz1176 das ist eine coole Webseite
Moin moin, erstmal geiles Video, dass es unter deutschsprachigen Programmierern sowas wie Clean Code gibt wusste ich gar nicht, das scheint im engischen Raum schon ziemlich "verbreiteterer" zu sein. Dafür schon einmal Kudos.
Zu Switch-Case-Anweisungen ist zu beachten, dass diese auch nur einfachere If-Anweisungen sind. Klar kann man das ganze auch Overengineeren, aber ich habe selbst festgestellt, dass nach nen paar Wochen und Monaten einen ein Switch-Case ziemlich in den Arsch beißen kann, vor allem wenn er in einem Modul steckt, welches von woanders benutzt wird.
Einfach, wie hier mag das noch gehen, wird aber ziemlich schnell unübersichtlich. Ich schreibe mir dafür dann einfach eine Klasse mit der entsprechenden Klassenfunktion und behandle darin alle Fälle, so muss ich dann nicht alle Switch-Cases durcharbeiten wenn sich etwas ändert.
In diesem Fall steht dem natürlich nichts im Weg, aber ich meine hinten raus. Wenn man etwas komplexer geworden ist.
MfG
Vielen Dank für dein Feedback :)
Gut, aber man sollte sich an die Allgemeinen Java conventions halten.
Wenn das viele machen, ist es sinnvoll.
Stimmt auch wieder. Wenn es niemand macht, dann war diese Vereinbarung völlig umsonst.
Das witzige ist, dass z.T. der Java Code vom Compiler automatisch nach deiner Regel "Error handling first" umgebaut wird. Ist mir letztens aufgefallen, als IDEA eine Klasse einer unserer internen Libraries decompiliert hat.
Kurze Frage zu dem Erklärten Beispiel bei 3:50, müsste man das upload_to_server() nicht in den else teil beim 2. If block einfügen? Weil sonst würde der doch einfach trotzdem uploaden oder?
Durch den return Befehl wird die Funktion beendet, egal, was dahinter noch kommt.
Bei 1:15, würde nicht die .isEmpty() Methode besser passen? Weiß nicht was besser ist, die "null" Überprüfung oder die "isEmpty()" Überprüfung.
Geht auch
Kannst du denn garantieren, das die Felder denn immer initialisiert sind? Ansonsten fliegt dir .isEmpty() mit einer NullPointerException um die Ohren.
@@TinyTeaKettle Da hast du natürlich recht ja. Bin aber davon ausgegangen, dass die Strings einen Wert haben.
@@GradientTim In dem Fall, wovon man selten ausgehen sollte, macht eine Überprüfung auf null sowieso nie Sinn. Das wäre ja dann das gleiche wie ein if(true) bzw. if(false)
Ich habe bisher immer nach dem Motto "Fehlerbehebung hat Vorrang" mit If-Anweisungen gearbeitet. Mein Freund mit dem ich öfter programmiere macht das nicht, das triggerd mich immer xD
Das fällt ihm früher oder später auf die Füße.
Ich mach das auch, erst alles prüfen und return / throw. Ich hab fast keine else und fast jedes if hat ein return, ich nutze viel continue und break...
Kollegen die das lesen bekommen sofort mit was die Methode nicht macht. Das enttäuscht falsche Erwartungen. Nach meinem Gefühl sind falsche Annahmen die größte Quelle von schwer zu entdeckenden Fehlern.
oder Sie können assoziative Maps wie folgt verwenden anstatt switch statement (Bespiel im Lua):
local map = { ["A"] = 10, ["B"] = 20, .... };
local input = "Hallo";
local output = map["Hallo"];
if(output == nil) then
print("Fehler: ungültige eingabe");
return;
end
Gibt es noch mehr Clean Code videos? Super erklärt!
Ich plane aktuell einen zweiten Teil 😉
"Schalteranweisung" ... :D . Hatte damals an der Uni einen (ziemlich alten) Prof, der immer "Kellerspeicher" gesagt hat, wenn er stack meinte. Hat ne Weile gebraucht, bis das alle Studis das gerafft hatten ...
Ist bei 3:55 die if nicht: if (!file.isMP3() || ! file.isPDF())
Sonst breche ich doch ab, wenn die Datei keine MP3 und keine PDF ist, das geht aber ja nicht, denn sie ist entweder MP3 oder PDF. Oder sitz ich gerade auf dem Schlauch?
Die if-Anweisung bricht nur ab, wenn die Datei weder mp3 noch pdf ist. Es werden so nur mp3 und pdf Dateien hochgeladen. Das ist also richtig.
@@cedrichartz390 Hast natürlich Recht, ich war gestern echt umnachtet. Heute angeschaut und mich über meinen eigenen Kommentar gewundert :)
Dem würde ich so zustimmen ;-)
Super :)
Negationen lesen sich immer recht schwer.
Also möglichst immer die positiv form verwenden wenn irgendwie möglich.
If allowedFileTypes.Contains(...) then Upload to server ... oder
if (mp3 || pdf) then Upload to server
Guter Tipp
Clean code ist ein wichtiger Ansatz. Aber gleichzeitig die Konventionen nicht einzuhalten finde ich dann schon recht unschön.
Funktionen schreibt man in camel case und für gewöhnlich in Englisch. Eine Funktion die ein boolean zurück gibt beginnt mit "is". Besser als mit != null zu vergleichen ist den konkreten Typ zu wählen, was in der regel === undefined ist.
"Sie sind aus der Programmierung nicht mehr wegzudenken und tauchen an vielen Stellen auf"
Ja, Programmierung ist ein wundervolles Abenteuer.
Das erinnert mich an die Zeit, als ich auf dem C 64 die Programmiersprache "C" gelernt habe und total stolz darauf war, das Prinzip von Funktionen verstanden zu haben und auch schon verschachtelte Funktionsaufrufe genutzt habe. Da habe ich mir zur Belohnung auch immer Marshmallows geröstet...
Ich hab ja bis dahin nur in Assembler programmiert und dort habe ich das, was Compiler und Linker tun, alles selber machen müssen. (wir hatten ja nichts)
Ach, was würde ich mir wünschen, würden die zwei ersten Semester Informatik daraus bestehen, einfache Funktionen wie Multiplikation und Division von Zahlen, die nicht in die CPU-Architektur passen, schreiben zu müssen - also z.B. 128 Bit lange Zahlen auf einer 8-Bit Architektur!
Man braucht nämlich auch heutzutage noch Kalkulationen mit Zahlen, die länger sind als 64 Bit - Weitaus länger! (RSA, Diffie Hellmann, Myer's Bit-Vector Algorythmus, u.v.a.)
Zum Ende des zweiten Semesters müsste die abschließende Prüfung daraus bestehen, die RSA Verschlüsselung oder den Diffie-Hellmann Schlüsselaustausch, den Huffmann- oder Arithmetischen Kompessor für eine Z80 CPU in Assembler zu programmieren.
Wer das übersteht, weiß wie Computer funktionieren und nur die sollen weitermachen dürfen! Der Rest kann ja immer noch Chemie, BWL oder Hauswirtschaft studieren...
Ich möchte mal ein "Clean Code" Video sehen, daß für PostScript gemacht wurde :-D :-D :-D
Das ist eine tolle Idee 😄
In den 80’ern Basic und Assembler auf C64 war lecker ;) C hätte damals zu sehr gerne gehabt.
irgendwie finde ich den Code bei 2:00 klarer als z.B. 2:19 zu lesen.
Hey, schönes Video c: Wer sich damit ausführlicher beschäftigen will dem kann ich „Clean Code“ von Robert C. Martins empfehlen
Diese Empfehlung empfehle ich ebenfalls 😉
Statt dem Schalterblock wäre in dem Fall ein Dictionary sauberer gewesen und dann einfach print(dict[ziffer])
Hätte man auch machen können
Tipp für den letzten Fall: lookup table
Guter Tipp!
Der letzte Fall ist ja nur stellvertretend für Dinge, die Wirklich einen Switch benötigen - z.B. wenn man keine fortlaufenden Zahlen hat, sondern mal eine 1, eine 2 und die 255...
Den gezeigten Fall hätte ich mit einer Liste/Array gelöst.
Eine weitere Möglichkeit, wenn man eine vollständige (oder Lückenfreie) Liste hat und anhand derer unterschiedlichen nicht-trivialen Code ausführen möchte, wären Funktionspointer in einer Liste oder anonyme Funktionen - wie auch immer die in den unterschiedlichen Sprachen genannt werden.
Ich kann gerade fühlen, wie einige Leute nun zu weinen anfangen, weil eben diese Methoden nicht mehr ganz so leicht zu lesenden Code erzeugen.
Aber wenn für Euer Programm folgendes Soran-Zitat aus "Star Trek: Treffen der Generationen" zutrifft "die zeit ist das feuer in dem wir verbrennen", werden Knaben zu Männern und Clean-Code wird zu einem Hindernis, Eure Ziele zu erreichen!
Bei 2:0 Braucht man kein IF man kann das Statment direkt zurück geben
Siehe 2:04
Wenn man keine 4 Sekunden warten kann zum Klugscheißen
@@keiichitw hahaha alter du bist der youtube kommentat comedian 😂
Man sollte noch erwähne dass lokale result Variablen die in diesem verschachtelten branches gesetzt werden (oder initial null wenn kein Fall zutrifft) das ganze noch verschlimmern und öfters mal zu null Rückgabe und dann nullpointerexceötkons. Führen. We nn man auf null Rückgaben nicht verzichten will, dann wenigstens in allen guards explizit „return null;“ schreiben, und nicht „Objekt result = null; if(guard()) return result;}
In den Fall hilft es auch Variablen generell nicht auf null zu initialisieren wen man davon ausgeht alle Fälle in if/else abzudecken.
Schade, dass es in Python keine switch Funktion gibt :/
Das stimmt! Man kann die aber so ähnlich bauen.
Gibt es in Perl auch nicht. Hat mich nie gestört. Dafür gibt es in Perl das "elsif", mit dem man switch recht gut ersetzen kann.
lässt sich in python ziemlich einfach mit einem dictionary lösen
Dazu habe ich übrigens schon ein Video gemacht: th-cam.com/video/sLBnFWlPVok/w-d-xo.html
sehr schönes Video .. meist kommen die Anforderungen im echten Entwickler-Leben aber zeitversetzt, dh. man hat eine if-Anweisung und muß weitere voneinander abhängige Bedingungen einbauen ohne dabei bestehenden funktionieren Code zu gefährden (da auch niemand da ist der die Änderungen am Ende testet *g) .. dh. man geht auf Nummer sicher (und nicht nach Schönheit des Codes) um den Produktiv-Betrieb nicht zu gefährden ... dann entsteht zwangsläufig "historisch gewachsener verschachtelter" Code .. den man aber nach 3-4 Jahren noch lesen kann wenn wenn man sich ein paar Kommentare dazu schreibt
👍
Tolles Video,
aber mit dem Switch bin ich nicht einverstanden.
In Clean Code sollte man auf Switch cases verzichten.
Switch cases machen den den Code u.u. extrem unlesbar.
Zusätzlich widersprechen sie, dem Prinzip, dass jede Methode nur eine Aufgabe haben darf.
Mein Tipp
Switch cases durch Dictionary ablösen. Wesentlich sauberer und verständlicher.
Vor allem wenn man durch Schnittstellen entkoppelt.
Da hat Python alles richtig gemacht. Hier gibt es NUR Dictionaries und keine Switch Cases.
Guten Tag
Hi
Why was thia recommended to me? I don't speak german
I don't know. YT algorithm is an enigma.
Instagram ist nice
Joaaaa
4:24 Python gerade: 👁️💧👄💧👁️
:D
Was ich mir eigentlich darunter vorstelle, wenn es um Clean Code und if-Anweisungen geht: if-Anweisungen so weit es geht durch polymorphe Methodenaufrufe ersetzen. Und if-Anweisungen hauptsächlich in Factories benutzen, um zu entscheiden, welche polymorphe Implementierung erzeugt werden soll.
Resultat: Komplexe if-Anweisungen verschwinden von ganz allein und verteilen sich auf unterschiedlich ausgeprägte Unterklassen. Zudem wird das Open-Closed-Prinzip gefördert 🔥
(vgl. Martin, 2009: Clean Code, S. 299)
👍
Einfach kein if/else benutzen, dann hat man die Probleme nicht. Ja, etwas provokant, aber meistens geht es auch ohne (-:
Hehe ... ja, man kann wirklich oft darauf verzichten.
Gar nicht provokant, sondern genau richtig. In meinem Job tue ich genau das: ich versuche, if so oft es geht zu vermeiden und else benutze ich nie. Sehr viele if(-else) Anweisungen existieren nur, weil der Programmierer keine neue Klasse erstellen wollte, obwohl das die bessere Option gewesen wäre. Es gibt dazu hier auf YT einen weunderbaren Vortrag von Sandi Metz ("all the little things"), in der sie das "Gilded Rose" Kata bespricht. Amfang des Vortrages steht eine if-else-Hölle, die keiner mehr durchblickt, am Ende stehen viele kleine Objekte und leicht verständlicher code, der sich einfach um neue Funktionalität erweitern lässt.
Poste gerne mal den Beitrag.
@@Florian.Dalwigk
Der hier ist es:
th-cam.com/video/8bZh5LMaSmE/w-d-xo.html
"Nothing is something" geht in bisschen in die gleiche Richtung (gegen if/else), behandelt aber einen anderen Fall, der für viele if/else im code sorgen kann:
th-cam.com/video/OMPfEXIlTVE/w-d-xo.html
@@Tekay37 Das ist schon richtig, aber ohne if geht es halt leider nicht. Deshalb mein "provokant" (-:
Wenn man
if{
}
Benutzt und nicht
If
{
}
Ich sehe es genau anders herum!
Und letztendlich gilt doch im Normalfall: Es ist das richtig, was die Firma vorgibt. Stichwort Styleguides.
Das letzte Beispiel gehört auf jeden Fall mit einer Mapping-Tabelle (z.B. assoziatives Array, dictionary) gemacht, bitte weder if noch switch für sowas...
Kann man machen ...
Leider wird (bei uns zumindest) auch heute noch auf der MISRA Regel "Nur ein return statement am Ende einer jeden Funktion" herumgeritten. Ich kann den Sinn dieser veralteteten Regel in der heutigen Zeit einfach nicht mehr erkennen und bin ebenso deiner Meinung, dass der Code so besser zu lesen ist. Selbst mit einer lokalen Variable für einen return code entstehen redundante Codezeilen die für den Betrachter unnötig sind.
Ja, diese Regel sorgt nicht selten dafür, dass man unsinnige Workaround drumherum bauen muss.
"If anwesungen sind aus der Programmierung nicht mehr wegzudenken"
ich glaub mein Hirn schimmelt.
If Anweisung sind die Definition von Digitaltechnik. Jeder transistor ist eine if Anweisung. Programme funktionieren nur wegen if Anwesungen. Ohne conditional jump ist eine maschiene nicht Turing komplett.
Du hättest diesen Satz über jedes Andere feature sagen können, nur nicht über if Anweisungen...
Und wo ist jetzt das Problem, dass man überall if-Abweisungen braucht?
@@Florian.Dalwigk der ganze Satz macht keinen Sinn.
"Zinken sind von modernen Gabeln nicht mehr wegzudenken" macht auch keinen sinn...
Ok, wenn du das so siehst.
@@hansdietrich83 Naja, ganz so ists auch nicht, man kann Verzweigungen auch per switch case umsetzen, wie im Video gezeigt, per pattern matching oder if expressions, ternärem operator usw... chill mal
Beispiel Kommentar um Leuten zu zeigen, was man unter ,,Deutsch“ versteht. Einfach ein Stock im Arsch zu haben ^^
Eigentlich ganz gutes Video. Aber Switch Case würde ich keinem mehr empfehlen. Das ist ein Relikt, das es zu vermeiden gilt (gerade das unschöne explizite break; welches erforderlich ist und der implizite Fallthrough macht switch case ziemlich hässlich). Besser auf ein Mapping zurückgreifen.
Gute Hinweis!
4:05 lol^^
nur schwarzer bildschirm
? 😅
Ja mei 😅
@@Florian.Dalwigk alles gut : ) deine videos sind sehr gut und hochwertig man lernt echt was
Eine Frage hast du dieses eine Hacker Mythen Cybersicherheit wegen den ganzen anderen Vorfaellen runtergenommen?
Ja, leider. Ich werde das Video aber nochmal YT freundlich aufnehmen und hochladen ;)
Ein weiterer Tipp: Wenn man sicherstellen kann, dass die Funktion immer mit validen Argumenten aufgerufen wird, kann man die Fehlerbehandlung weglassen 😉 Hört sich erstmal super banal an, aber die die mehr Erfahrung haben, wissen wovon ich rede 😂 Log-and-Throw Pattern at it's best 🙃
👍