DIPL.-ING. MARTIN WEITZEL, 64380 ROSSDORF, GERMANY

Home   •   mc-cleancode2024w37

mc-cleancode2024w37

Mttwoch = "große" Refactoring-Aufgabe

Anfäglicher Code
https://godbolt.org/z/61MT8xW1K

Aufgabentext (wird laufend erweitert)
https://docs.google.com/document/d/1Gp4do9xLf8Lfha6G3gOxW_qHW5t-ICFuDxjjwXUqtkI/edit?usp=sharing

 

Zwischenschritte:

Ad hoc Link-Sammlung zur Schulung "Clean-Code" vom 9. bis 11. September 2024

  • steht auch noch einige Zeit nach Ende des Kurses zur Verfügung
    • d.h. kein geplanter Termin zur späteren Löschung, aber auch
    • KEINE GARANTIE, dass die Seite sozusagen "für immer" bleibt
  • wenn einige der entrrhaltenen Links von Dauerinteresse sind, dann diese bitte herauskopieren und selbst aufbewahren – Danke

Einige kompilerbare Code-Beispiele Matt Godbolt's Online-Compiler:

Sammlung von Links zu Übungen und Musterlösungen (als Projekte mit Online-Compiler `online.gdb`)

  • TBD
  • ...

 

Weitere in der Schulung erwähnte Links, die eventuell von Interesse sein könnten.

Eine meines Erachtens sehr gute Diskussion über die "Substitubilität", die mit dem Buchstaben "S" im LSP gemeint ist. (Und das LSP ist ja wiederum "zenraler :-)" Bestandteil der SOLID-Prinzipien

Es basiert auf der Betrachtung von "Pre-Conditions" und "Post-Conditions" der Operationen einer Klasse (in C++ also deren Member-Funktionen) und wie und warum diese Eingrenzen, wann "Vererbung" sinnvoll ist und wann besser eher "Komposition" verwenden sollte.

 

Ein ChatGPT-Dialog zu Smart-Pointer. ich hatte den kurz vor dem Kurs für einen andere Schulung erstellt, passt aber auch hier ganz gut da das Thema "Smart-Pointer" angesprochen wurde (vor allem Hilfsmittel, wenn es um die Verknüpfung der "Hauptklassen" einere Applikation im Sinne der "Dependency Inversion" geht - also das "D" der SOLID-Prinzipien).

Man kann darüber streiten, ob man Smart-Pointer direkt zu "Clean-Code" zählen sollte oder nicht, aber in einer Sprache OHNE "Garbage Collection" sind sie auf alle Fälle der "robustere" Mechnaismus im Vergleich zu über "klassiche Pointer" verwalteten HEAP-Speicherplatz.

Ein ChatGPT-Link zu (m)einem gegenwärtigen "Projekt", den "Clean-Code"-Ansatz direkt aus dem Blickwinkel  von C++ als "Multi-Paradigmen-Sprache" anzugehen, nicht lediglich als eine "Syntax-Variante" von C#.

Letzteres auch OK, WENN man sich dabei auf die "klassichen" OOP-Mittel (Klassen, Vererbung, Interfaces etc.) beschränkt. Da die Schulung diese Woche "OOP" diirekt im Titel hat (und mit drei Tagen Dauer auch nicht um beliebig viel neuer Stoff erweitert werden kann), ist es in dieser Form vollkommen in Ordnung. Aber C++ bietet mehr als nur "klassische OOP" und alles auszuklammern, was es nicht zugleich auch in C# gibt, verzichtet auf viele Möglichkeiten, besseren Code in C++ zu schreiben im Sinne von "clean" und zugleich "robust".

Ergänzend verwendete Infografiken:

Arianne Softwarefehler (mein Argument `static_assert` an Stelle von Kommentaten zu verwenden):

Schlusswort (mea culpa):

Ich hatte irgendwann am ersten Tag im Zusammenhang mit der Berechnung der Zahk der Tage eines Monats fälschlich gesagt, dass man es sich einfach machen kann, wenn man nur den Zeitraum von 1601 bis 2399 abdecken will. (Auch ChatGPT hat das so hingenommen.)

  • Aber dazu müssten zuerst noch die 100-Jahre Ausnahmeregel rein.
  • Und wenn man die mit dazu nimmt, dann muss AUCH die 400-Jahre Ausnahmeregel rein.
  • Denn sonst ist es ausgerechnet im Jahr 2000 falsch!

Implementiert man dagegen lediglich die 4-Jahre Regel für Schaltjahre, dann funktioniert es immerhin im Zeitraum von 1901 bis 2099 korrekt, was für den überwiegenden Teil der heute entwickelten Software erst einmal reichen sollte ...  :-). Daher Danke an Kursteilnehmer Pascal D.,  der mich auf meine urprünglich falsche (und nunmehr korrigierte) Darstellung aufmerksam gemcht hat, man könne eine vereinfachte Implementiertung schfreiben, die von 1601 bis 2399 funktioniert - NEIN, das kann man nicht. Aber JA, von 1901 bis 2099 geht es. Eigentlich ein schönes Beispiel für YAGNI - oder nicht? 

Published on