Guter Code

[mensch72]

..."Guter Code"...
1.: es ist erklärbar, warum er funktioniert(das ist leider relevant! wenn gerade(noch) etwas geht, aber der Letzte welcher es gemacht&verstand nicht mehr da und es aktuell sonst keiner weiß, dann ist dies auf Dauer schlimmer wie wenn akut nix mehr gehen würde)
2.: er funktioniert hier&jetzt
3.: er funktioniert möglichst lange
4.: es ist schön, wenn Sachen Projekt übergreifend mehrfach nutzbar und strukturell sind, aber ich beharre nicht auf zwanghafter direkter 100% 1:1 "Dauer-Kompatibilität"
5.: muss nicht schön sein, er muss nur in sich einheitlich und somit für den Lesenden jeweils "vorhersehbar/erkennbar" sein


Von "sprechendem/selbsterklärendem Code mit dafür nur den notwendigsten Kommentaren jenseits der Funktion sowie Inputs und Outputs" oder "viel sprechende Kommentare, wo man dann teils schon den eigentlichen Code suchen muss"... ich arbeite nach diesen 5 Grundsätzen sowohl alleine als auch im Team.

Ich toleriere auch einen abweichenden Style anderer, und das sogar gern... einfach weil es gut ist, wenn man schon nach 2 Bildschirmseiten "sicher" erkennt wer das programmiert hat. Man weiß wenn was nicht(mehr) klappt an wen man sich wenden muss bzw. bei den "Ex...", an wen man sich nicht mehr direkt wenden kann.

Speziell beim Einsatz von internen oder externen Libs ist es auf Dauer nicht machbar, stets immer den gegenseitig neues Stand einsetzen zu wollen, wenn die Designzyklen nicht zu einander passen.
Es macht keinen Sinn, sich monatlich die aktuellsten Sachen von TMS,DevExpress,Intraweb,??? im Produktivsystem zu installieren, wenn man selbst nur einen Releasezyklus von 6+Monaten hat.
Es gilt oft: "NeverChancgeRunningSystem"... der unbeeinflussbar extern verursachte Testaufwand steigt sonst ins unermessliche.

Bei erkannten und dokumentierten Fehlern gilt zunächst immer "now: it's not a Bug... it's a Feature"!
Heißt wenn sichere wenn auch teils unkomfortable Workarounds zur Vermeidung von oder als Lösung für bekannte Fehler möglich, dann ist dies für Anwender doof, aber besser es eine Zeit zu beachten, als sich mit zig Updates bis zur nächsten stabilen Releaseversion "live" zu quälen.
Da schließt sich dann der Kreis: "guter Code" verhält sich auch im Fehlerfall soweit irgend möglich "vorhersehbar" und unterstützt die Fehleranalyse durch eigene aussagekräftige Logs der jeweils wesentlichen (Fehler) Informationen... und so blöd es klingt: da gibt es kein Standard Designpattern was das schafft... da hilft nur pure (eigene) Erfahrung.