Guter Code

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

Zitat:

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

...die lernen auch dazu.

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

[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 von Solutor:

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

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

[himitsu]

Zitat:

denn dafür gibt es Tools (Blame)

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

[Delphi-Laie]

Zitat von 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.

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

[himitsu]

Sag das mal den Lehrern.
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 )
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.