Guter Code

[p80286]

Zitat von PascalDeveloper:

und was man möglichst in der Programmierung in Pascal bzw. Delphi vermeiden sollte.

Guter Code
...ist der, der unter allen Umständen funktioniert. Wenn ein dressierter Affe mit deinem Programm umgehen kann ist es gut, und wenn auch mehrere hellhaarige Hairstylistinnen es nicht zum Absturz bringen ist es besser.
... ist der, der sich von unerwarteten Daten nicht vom Pfad der Tugend abbringen läßt.

...enthält kein with..do , denn oft genug versteht der Compiler das nicht so wie der Programmierer.
...enthält kein if Boolvar=True .
...enthält keine relativen Dateinamen.
...enthält keine Pointerarithmetik.
...ist durch richtige Kommentierung auch nach 3..n Monaten noch verständlich.

Gruß
K-H

[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.

[haentschman]

Moin...
Zum Programmieren gehört aber nicht nur guter Code sondern auch ein Versionskontrollsystem...Nicht beim ersten Formular, aber besser gleich am Anfang.

[TigerLilly]

Die Frage nach gutem Code führt zu vielen Antworten. Eine präzisere Frage wäre vielleicht: Was ist brauchbarer Code und was ist schöner Code.

Programmieren ist ja nicht nur einen Ingenieurwissenschaft (=brauchbarer Code) sondern auch eine Kunst (=schöner Code). Für ersteres gibt es handfeste Kriterien und Designprinzipien:
https://t3n.de/news/prinzipien-softw...-solid-615556/
https://glossar.hs-augsburg.de/Programmierprinzipien

Zweites ist wie so oft Geschmackssache und soll mit ersterem nicht verwechselt werden.

[Luckie]

Ich habe her http://michael-puff.de/Programmierun...leanCode.shtml die wichtigsten Punkte aus dem Buch Clean Code von Robert C. Martin zusammen getragen.

[p80286]

Also was die Kommentierung angeht, bin ich der Meinung, daß z.B. API-Aufrufe immer kommentiert gehören. Aber darüber kann man trefflich streiten.
Da ich mit dem IBM-BIOS aufgewachsen bin, kommentiere ich u.U. etwas zu viel.

Gruß
K-H

[himitsu]

Ein paar Beispiele für nicht immer sehr gute Kommentare und Codes.
http://www.delphipraxis.net/96226-eu...ommentare.html

@Herr Puff, sie wurden schon 5 Kommentare vorher verpetzt.

[Luckie]

Zitat von himitsu:

@Herr Puff, sie wurden schon 5 Kommentare vorher verpetzt.

Wenn ich den erwische!

[PascalDeveloper]

Vielen Dank für die Antworten ich habe mir jetzt das Buch Clean code von Robert C. gekauft welches sehr gut ist und ich nur weiterempfehlen kann

[Solutor]

Der Vorschlag guter Code....
...enthält kein with..do , denn oft genug versteht der Compiler das nicht so wie der Programmierer.

Widerspricht dem was Borland in seinen Handbüchern zur Programmierung empfiehlt.

Es ist korrekt, dass dies nicht immer zu empfehlen ist, erst recht wenn man das Ganze verschachtelt.
Ich mache dies oft bei Ereignisbehandlungsmethoden wie OnDrawCell usw.
Man muss hierbei einfach nur wissen, ob bestimmte Parameter und Eigenschaften/Variablen sich da nicht gegenseitig in die Quere kommen.
Einige Variablen/Methoden sind in verschiedenen Units vorhanden und haben daher trotz gleichen Namens einen anderen Bezug.

Doch jedes Mal voll zu referenzieren, macht viel Tipparbeit und den Code nicht immer übersichtlicher.

Wenn man ungewöhnliches macht, bzw. unerwartetes, dann hilft einfach ein entsprechender Kommentar um das Ganze zu erläutern.