Guter Code

[PascalDeveloper]

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.

[haentschman]

Moin...:P

Erst Mal Willkommen hier...:dp:

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...:wink:
* Trennung von Logik und Anzeige. (getrennte Units)
* Camel Case statt Unterstriche. https://de.wikipedia.org/wiki/Binnen...ammiersprachen

...ansonsten nicht aufgeben. :zwinker:

[himitsu]

für Gutes:
delphi style guide
pascal style guide

[OlafSt]

Zitat:

Zitat von haentschman (Beitrag 1393835)

Moin...:P

* Code den du verstehst.

Ich vermisse da ein "in 12 Monaten immer noch" 8-)

[FBrust]

Hallo,

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

Clean Code

Gruß
Frank

[haentschman]

Zitat:

Ich vermisse da ein "in 12 Monaten immer noch"

...mit zunehmenem Alter wird der Zeitraum immer kürzer. :roll: :P

[rokli]

Zitat:

Zitat von haentschman (Beitrag 1393835)

* sprechende Namen (statt: Form186, Edit465)

Haentschman findest Du Edti465 wirklich besser wie Form186 ? :lol:



Edit: Tippfehler beseitigt

[rokli]

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

[p80286]

Zitat:

Zitat von PascalDeveloper (Beitrag 1393831)

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

Delphi-Quellcode:

with..do

, denn oft genug versteht der Compiler das nicht so wie der Programmierer.
...enthält kein

Delphi-Quellcode:

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...:P
Zum Programmieren gehört aber nicht nur guter Code sondern auch ein Versionskontrollsystem...Nicht beim ersten Formular, aber besser gleich am Anfang. :thumb:

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

[bernau]

Zitat:

Zitat von haentschman (Beitrag 1393835)

* nicht alle Units in einen Ordner! Vernüftige Struktur auf der Festplatte...:wink:

Seit es Namespaces gibt, fange ich an die Verzeichnissmenge einzuschränken.

Ein großes 20 Jahre altes Projekt von mir, hat ca. >800 Units, die auf 60 Verzeichnisse verteilt sind (waren). Bin seit ca. 12 Monaten dabei, die Unitnamen umzubenennen und in "ein" Stammverzeichnis zu verschieben. Für mich sind die Dateien viel besser zu suchen und die Units ist besser kategorisiert. Vorher natürlich Gedanken über den Aufbau und die Benennung der Namespaces machen.

Aber das ist natürlich Geschmackssache.

[himitsu]

Jupp, die Namespaces machen einem das Leben leichter.

Häßlicher Code:

Delphi-Quellcode:

>++++[<++++++++>-]>++++++++[>++++<-]>>++>>>+>>>+<<<<<<<<<<[-[->+<]>[-<+>>>.<<]>> >[[->++++++++[>++++<-]>.<<[->+<]+>[->++++++++++<<+>]>.[-]>]]+<<<[-[->+<]+>[-<+>> >-[->+<]++>[-<->]<<<]<<<<]++++++++++.+++.[-]<]+++++

Schöner Code:
https://github.com/pablojorge/brainf.../sierpinski.bf

oder
http://www.linusakesson.net/programming/brainfuck/

Online zum Testen:
https://copy.sh/brainfuck/
https://fatiherikli.github.io/brainfuck-visualizer

In Delphi ist man zwar nicht ganz so frei, aber dennoch kann man Codes schöner (augenfräundlicher) gestalten.
Oder so hinklatschen, dass dich jeder erschlagen will, der das lesen muß.


Am Augenfreundlichsten und beim Ausdrucken extrem tintesparend ist die Programmiersprache Whitespace, die ähnlich dem Brainfuck ist.

[bernau]

@himitsu

Was soll dieser Beitrag einem sagen?

Was hat Brainfuck mit Namespaces zu tun?

[jaenicke]

Zitat:

Zitat von bernau (Beitrag 1393922)

Seit es Namespaces gibt, fange ich an die Verzeichnissmenge einzuschränken.

Wir haben im Gegenteil die Verzeichnisse analog zu den Namespaces aufgebaut. Sprich Common.Utils.StringTools.pas liegt in Repository\common\utils usw.
Klassen und Interfaces heißen analog zu den Unitnamen. Auf die Weise findet man erstens schnell eine bestimmte Unit, zweitens thematisch schnell ein passende Unit und drittens einfach eine Unit zu einem Typen. Letzteres ist mit ModelMaker Code Explorer sicherlich nicht mehr so das Thema, aber ich finde es dennoch am übersichtlichsten.

[himitsu]

@bernau: Denk dir einen Trennstrich dazwischn.

Antwort zu deinem Post
----------------------
Antwort zum Thread

[bernau]

Zitat:

Zitat von himitsu (Beitrag 1393930)

@bernau: Denk dir einen Trennstrich dazwischn.

Ahh. Was so ein Trennstrich für die Interpretation eines Post ausmacht. :wink:

Im ersten Moment sah es so aus, daß man bei Verwendung von Namespaces auch gleich die Sprache Brainfuck verwenden kann.

Ein guter Forumbeitrag ist wie guter Quellcode. Andere müssen ihn verstehen können. Passst zum Thema :lol:

[Delphi-Laie]

http://michael-puff.de/Programmierun...kel/Enum.shtml
http://michael-puff.de/Programmierun...leanCode.shtml

[Sherlock]

Ich hab irgendwo mal eine schöne Liste von typischen Delphi Anti-Patterns gelesen, aber leider find ich die nicht mehr. Verdammt! Da sind halt so Sachen drin gewesen wie "Logik in der Ereignisbehandlungsroutine", graphische Objekte mit durchnumerierten Bezeichnern etc.

Und ich meine nicht das Video von Alistair Christie zu diesem Thema, es war schriftlich...sowas wie ein Blogbeitrag oder so.

Sherlock

[freimatz]

Zitat:

...ist durch richtige Kommentierung auch nach 3..n Monaten noch verständlich.

Nein, benötigt keine Kommentierung. Wenn ein Code einer Kommentierung bedarf die erklärt was der Code macht ist der code schlecht.
Gut ist Kommentierung nur, wenn sie erklärt WARUM es gemacht wird.

Zitat:

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.

Den Grund lasse ich nicht gelten, denn dafür gibt es Tools (Blame)

Das Wichtigste für mich ist immer noch:

Zitat:

Clean Code

Da ist eigentlich alles andere hier mit drin.

Und außerdem: Es freut mich shr dass du dich für guten Code interssierst. Das ist schon mal die Grundvoraussetzung. :-D

[himitsu]

Zitat:

denn dafür gibt es Tools (Blame)

Wenn er das aber umformatiert und eincheckt, dann steht er selbst dort als "Schuldiger" drin. :lol:

[Delphi-Laie]

Zitat:

Zitat von freimatz (Beitrag 1393963)

Zitat:

...ist durch richtige Kommentierung auch nach 3..n Monaten noch verständlich.

Nein, benötigt keine Kommentierung. Wenn ein Code einer Kommentierung bedarf die erklärt was der Code macht ist der code schlecht.
Gut ist Kommentierung nur, wenn sie erklärt WARUM es gemacht wird.

Was der Code macht, muß man nie erklären, denn das sieht man ja selbst.

[himitsu]

Sag das mal den Lehrern.

Delphi-Quellcode:

i := i + 1;  // Addiere 1 zur Variable i

Ich hatte hier in der DP einmal das beste Antipattern für Überkommentierung gesehn, da war wirklich jeder einzelne Befehl kommentiert.
(leider vergessen mir den Post zu merken :cry:)
Nachbauen kann ich diesen Antipattern leider nicht. Hatte ich schon versucht, aber so schön bekam ich das einfach nicht hin.

Das Ergebnis war, dass man den einzigen "wichtigen" Kommentar so garnicht bemerkte. :roll:

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

[Luckie]

Zitat:

Zitat von himitsu (Beitrag 1393976)

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

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 ausführlich und informativ ist.

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

[haentschman]

Moin...:P

Zitat:

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

...die lernen auch dazu. :zwinker:

Hast du schon mal einen Fehler gesucht in Quelltext den du nicht programmiert hast und der von with strotzt? Wahrscheinlich nicht. Denn du wirst fluchen, das du im Debugger keine Variablenwerte siehst! Das ist ein NoGo für mich...ein gutes Werkzeug nicht benutzen zu können!
Viel Spaß...:roll:

[hoika]

Hallo,
also ich bin eigentlich ein Verfechter des with in Zusammenhang mit Queries,
weil es einfach so schön einfach ist.

Delphi-Quellcode:

var
  Q: TQuery;

..

with Q do
begin
  SQL.Clear;
  SQL.Add()
  Open;
end;
Close;

Aber gerade für Anfänger ist das sehr schwer (Stichwort Debugging, wie oben schon geschrieben wurde).

Such-Rätsel:
Wer findet den obigen Fehler ?

PS: Der war wirklich so in einem (Anfänger-) Code ...

[TigerLilly]

Zitat:

Zitat von Solutor (Beitrag 1394860)

... Man muss hierbei einfach nur wissen, ob bestimmte Parameter und Eigenschaften/Variablen sich da nicht gegenseitig in die Quere kommen.
...
Wenn man ungewöhnliches macht, bzw. unerwartetes, dann hilft einfach ein entsprechender Kommentar um das Ganze zu erläutern.

Na eben nicht. Ein Styleguide, eine SOP, good-code-principles etc haben eben den Zweck, dass man nicht nachdenken soll, wie man bestimmte Dinge angeht. Denn wenn ich jedes Mal nachdenke + entscheide, ob ich von meiner Vorgabe abweichen kann, weil da eh nichts passiert, habe ich schon genau die Fehler, die ich mit meinen Vorgaben verhindern wollte.

Wem die Tipparbeit zu viel wird, kann ja eine Variable benutzen + mit der weiterarbeiten.

@Kommentar: Wenn so ein Kommentar notwendig ist, ist das ein Hinweis auf schlechten Code.

[Sherlock]

Natürlich ist Quelltext selbsterklärend. Aber genauso natürlich gibt er nicht die Absicht des Entwicklers preis, die den Hintergrund seines Entstehens bildet.
Wenn also in einer Methode zum auffinden und löschen von Dubletten in einer Personen-Tabelle plötzlich Bestandteile eines Dienstes angehalten werden...kommentarlos (wie ich gerade gestern in einem Python Stück fand), dann darf man sich schon mal wundern.

Edith mahnt noch, daß sie keinesfalls ein "egal, welche Absicht hinter Code steckt, so lange er lesbar ist" hören möchte.

Sherlock

[himitsu]

Für kurzen Code und vorallem nicht verschachtelt, kann WITH auch mal praktisch sein und manchmal sogar den Code lesbarer machen,
aber der Code im WITH sollte dann nicht zu lang sein (dafür nimmt man ja meistens WITH, um zu kürzen) und nach Möglichkeit sollte nichts "Mehrdeutiges" drin vorkommen.

Lesbarer/Optimaler bei

Delphi-Quellcode:

with irgendwasgaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaanzlangem do

das dann anschließend mehrmals verwendet wird.
Ist dieses "irgendwas" etwas, dass aufwauch ändig/langatmig ist, dann wird hierdurch die Ausführung beschleunigt, aber das Gleiche würde man auch mit einer einbuchstabingen Variable erreichen.

Billiges Antibeispiel:

Delphi-Quellcode:

procedure TMyForm.AnEvent(...);
begin
  with MyTRectVar do
    Width := Right - Left + 1;
end;

Früher ging das, da

Delphi-Quellcode:

{Self.}Width := {MyTRectVar.}Right - {MyTRectVar.}Left + 1;

,
aber dann wurde was Neues erfunden. Types.TRect.Width :lol:

[Delphi.Narium]

Zitat:

Zitat von hoika (Beitrag 1394888)

Hallo,
also ich bin eigentlich ein Verfechter des with in Zusammenhang mit Queries,
weil es einfach so schön einfach ist.

Delphi-Quellcode:

var
  Q: TQuery;

..

with Q do
begin
  SQL.Clear;
  SQL.Add()
  Open;
end;
Close;

Aber gerade für Anfänger ist das sehr schwer (Stichwort Debugging, wie oben schon geschrieben wurde).

Such-Rätsel:
Wer findet den obigen Fehler ?

PS: Der war wirklich so in einem (Anfänger-) Code ...

Frage ernst gemeint?

Abfrage öffnen und Programm beenden ;-)

Man wird das Ergebnis halt nie zu Gesicht bekommen, aber das das SQL leer ist, ist das weiter nicht schlimm ;-)

@All
Und ja: Mit With arbeiten spart Schreibarbeit.
Und ja: Für die Fehlersuche braucht man entsprechend länger (oft viel länger, als die eingesparte Schreibarbeit).

Bei with muss man sehr genau wissen, welche "Querschläger" es geben kann und diese alle ausschließen.

Das ist fast unmöglich, also ist die zusätzliche, angeblich vermeidbare "Schreibmehrarbeit", nur in sehr seltenen Fällen eine wirkliche Ersparnis.

Oft ist es sinnvoller, auf with zu verzichten (wer konsequent immer drauf verzichtet, macht nix falsch). Das, was man zusätzlich schreiben muss, ist immer identisch und kann per Copy&Paste jeweils mit sehr wenig Schreibarbeit (eimal Strg+C und dann Strg+V) wiederholt eingefügt werden.

Meine Erfahrung mit with ist eigentlich: Insbesondere in fremden Code kann es sehr verwirrend sein, wenn der verbleibende Quelltext zwar kompilierbar und sogar korrekt ausführbar ist, aber Zusammenhänge nicht mehr zwingend erkennbar sind.

[jaenicke]

Man sieht bei Upgrades der Delphiversion immer wieder in welcher Delphi-Bibliothek wieder jemand with benutzt hat. Denn das fällt ständig auf die Füße. Ohne with hätte ich viele Quelltexte von Delphi 7 einfach so unter 10.2 kompilieren können. Nur with muss ich bei jeder Version irgendwo korrigieren... :roll: Und dann auch noch erst einmal herausfinden wie genau ich das korrigieren muss... :roll:

[Delphi-Laie]

Zitat:

Zitat von jaenicke (Beitrag 1395077)

Man sieht bei Upgrades der Delphiversion immer wieder in welcher Delphi-Bibliothek wieder jemand with benutzt hat. Denn das fällt ständig auf die Füße. Ohne with hätte ich viele Quelltexte von Delphi 7 einfach so unter 10.2 kompilieren können. Nur with muss ich bei jeder Version irgendwo korrigieren... :roll: Und dann auch noch erst einmal herausfinden wie genau ich das korrigieren muss... :roll:

"with" benutzte ich nur früher ausnahmsweise, wohl eher, um es auszuprobieren, seit vielen Jahren jedoch nicht mehr. Ganz einfach, weil es auch für mich selbst die Programmlesbarkeit erschwert. Die Tipperei ist für mich jedenfalls kein Argument, außerdem kann man ja "Guttenberg spielen".

Wenn ich die nicht enden wollende Kritik an diesem "Komfortbefehl" lese, ist "with" also irgendwo zwischen bäh-bäh und ziemlich bis ganz böse einzuordnen.

Vielleicht sollte man es auf den Index setzen, so, wie es den armen Labels und dazugehörigen Gotos geschah. Wobei ich letztere dosiert doch verwende.

[dummzeuch]

Nur mal so am Rande:

With gibt es auch verschärft:

Delphi-Quellcode:

with A, B, C, D do
  PropertyVonA := MethodVonB(FieldVonC, MethodVonD);
end;

Wer solchen Code noch nicht gesehen hat, sollte sich für die Gnade seiner späten Geburt bedanken. Das war zu Turbo/Borland Pascal-Zeiten leider durchaus üblich. Und noch schlimmer: Auch ich habe damals solchen Code geschrieben.

Wenn sich dabei auch nur einer der 4 Typen minimal ändert, knallt es gewaltig.