Also gut, wenn du schon einen eigenen Thread aufmachst, dann machen wir eben weiter
Socke hat geschrieben:Genau diese Information stand gar nicht zur Verfügung; hättest du mit einem Kommentar darauf hingewiesen, hätte m.fuchs (oder du) einen entsprechenden Namen wählen können.
Der Code stand hier nur als Beispiel dafür, dass Zuweisungen in einer Abfrage sinnvoll sein können. Und da ist es übrigens völlig egal, ob dieser Code in eine eigene Prozedur ausgelagert ist oder nicht.
Kommentare dienen dazu, sich in einem umfangreichen Programm schnell zurechtzufinden.
Socke hat geschrieben:Spätestens wenn ich einen bereits vorhanden Code an anderer Stelle nochmals brauche, mache ich eine eigene Funktion daraus.
Spätestens wenn ich einen bereits vorhanden Code an anderer Stelle nochmals brauche,
oder wenn ich damit rechne, dass ich den Code an anderer Stelle nochmals brauchen werde, mache ich eine eigene Funktion daraus.
m.fuchs hat geschrieben:Kommentare haben leider die Angewohnheit zu verrotten. Das heißt bei Änderungen werden sie nicht unbedingt gepflegt.
Man sollte sich angewöhnen, Kommentare zu pflegen.
m.fuchs hat geschrieben:Aber idealerweise muss man heutzutage nicht mehr kommentieren. Der Quellcode sollte für sich selbst sprechen.
Wenn das Programm durch extrem viele Einzeiler-Funktionen zerfleddert ist, spricht es sicher nicht für sich selbst. Aber auch sonst gehört auch "heutzutage" jeder Code anständig kommentiert.
m.fuchs hat geschrieben:Das ist der Beweis, ich habe aus deinem Code nicht verstanden was du eigentlich machen möchtest.
Das meinst du hoffentlich nicht ernst
m.fuchs hat geschrieben:Ich verweise auch noch einmal auf mein Beispiel aus einem anderen Thread:
Code: Alles auswählen
if (Domain.ExpireDate < Now) and (Domain.Active) and (not Domain.Customer.Locked) and (Domain.Customer.DunningLevel < 2) then
vs.
Wenn du diese Abfragen nur an dieser Stelle des Programms und sonst nirgends brauchst, dann ist m.E. besser
Code: Alles auswählen
// Überprüfe alle Bedingungen, unter denen die Domain erneuert werden soll
if (Domain.ExpireDate < Now) and (Domain.Active) and (not Domain.Customer.Locked) and (Domain.Customer.DunningLevel < 2) then
Beim Lesen des Programms kann man dann problemlos über die Details der Bedingungen drüberlesen, wenn sie einen nicht interessieren.
Tipp: Einzeiler lassen sich problemlos rekursiv erweitern, wenn du als Programmierer pro Programmzeile bezahlt wirst:
Code: Alles auswählen
procedure tuwas;
begin write ('Ich tu was') end;
procedure RufeTuWasAuf;
begin
tuwas;
end;
procedure RufeRufeTuWasAufAuf;
begin
RufeTuWasAuf;
end;
procedure RufeRufeRufeTuWasAufAufAuf;
begin
RufeRufeTuWasAufAuf;
end;
...
begin
RufeRufeRufeRufeRufeRufeRufeRufeRufeRufeRufeRufeRufeRufeRufeTuWasAufAufAufAufAufAufAufAufAufAufAufAufAufAufAuf;
end.
m.fuchs hat geschrieben:Wenn man sein Programm vernünftig ... strukturiert ist es gar kein Problem.
zum "vernünftig strukturiert" gehört auch, dass man es NICHT durch eine Inflation von Einzeiler-Prozeduren zerfleddert.
m.fuchs hat geschrieben:Lazarus unterstützt Strg+Klick auf den Funktionsnamen. Wenn du wirklich in den Quellcode der Funktion schauen willst hilft das ungemein. Da muss man nichts suchen.
Wenn es um eine einzelne Funktion geht, ja. Wenn das Programm aus lauter Funktionsaufrufen besteht, in denen Einzeiler erledigt werden, verlierst du vor lauter Strg+Klick die Übersicht.
Abgesehen davon bin ich da der Meinung von MSE, dass ein Programm auch als Text außerhalb einer IDE lesbar sein sollte.
pluto hat geschrieben:Solange man damit nicht übertreibt
Genau darum geht es mir. Natürlich sollte man sein Programm durch eine
adäquate Aufteilung in Prozeduren, Funktionen und Methoden sinnvoll strukturieren.
pluto hat geschrieben:Es gibt eine Funktion, die einen / oder ein \ am Ende einens Dateinamens hängt. Ich finde den Namen dieser Funktion extrem Lang.
Genauso gut, kann man es selbst machen.
Weil ich brav bin, verwende ich prinzipiell diese Funktion - muss den Namen aber jedes mal in der Hilfe suchen, ich schaffe es einfach nicht, mir den zu merken.