Guten Tag Community,
ich bin ziemlich neu in der Programmierung und mich würde Interessieren was erfahrene Programmierung
als guten Code bezeichnen, und was man möglichst in der Programmierung in Pascal bzw. Delphi vermeiden sollte. Schon mal
Danke für die Antworten.

Moin...

Erst Mal Willkommen hier...

Guter Code ist:
* Code den du verstehst.
* Code den Andere lesen können. Styleguide: https://www.delphi-treff.de/object-pascal/styleguide/
* sprechende Namen (statt: Form186, Edit465)
* nicht alle Units in einen Ordner! Vernüftige Struktur auf der Festplatte...
* Trennung von Logik und Anzeige. (getrennte Units)
* Camel Case statt Unterstriche. https://de.wikipedia.org/wiki/Binnen...ammiersprachen

...ansonsten nicht aufgeben.

für Gutes:
delphi style guide
pascal style guide

Zitat von haentschman:

Moin...

* Code den du verstehst.

Ich vermisse da ein "in 12 Monaten immer noch"

Hallo,

vielleicht bringt Dir das ja auch ein paar Denkanstöße:

Clean Code

Gruß
Frank

Zitat:

Ich vermisse da ein "in 12 Monaten immer noch"

...mit zunehmenem Alter wird der Zeitraum immer kürzer.

Zitat von haentschman:

* sprechende Namen (statt: Form186, Edit465)

Haentschman findest Du Edti465 wirklich besser wie Form186 ?



Edit: Tippfehler beseitigt

Moin PascalDeveloper,

ganz entscheidend wird sein, ob Du allein arbeitest, oder ob Du in einem Team entwickelst. Im Team bekommst Du sicherlich die Regeln des Arbeitgeber / Abteilung vorgegeben.

Wenn Du allein arbeitest, hast Du mehr Freiheitsgrade, aber die Tipps in den vorherigen Posts bringen schon ganz viele Informationen und auch für Dich allein ist ein guter Stil beim Coding, insbesondere, wenn Du Monate oder Jahre später da wieder ran musst, sehr hilfreich.

Und vergiss die Kommentare nicht; eine schwierige Logik oder auch wenig geläufige Prozeduren und Funktionen freuen sich über einen aussagekräftigen Kommentar.

Grüße

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

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