Zitat von
jfheins:
Noch ein Beispiel:
Delphi-Quellcode:
procedure TFtpBrowser.DeleteFile (AFile: String; IsDir: Boolean);
begin
if (IsDir and (AFile <> '.') and (AFile <> '..')) then
begin
try
DeleteAll(AFile);
FFtp.RemoveDir(FDir.Text + AFile);
except
TriggerLogEvent('Could not remove directory ' + AFile, etError);
end;
end
else if (not IsDir) then
begin
try
FFtp.Delete (FDir.Text + AFile);
except
TriggerLogEvent('Could not remove file ' + AFile, etError);
end;
end;
end;
Bei mir würde das so aussehen:
Delphi-Quellcode:
procedure TFtpBrowser.DeleteFile(AFile: String; IsDir: Boolean);
begin
if (IsDir and (AFile <> '.') and (AFile <> '..')) then
begin
try
RemoveFilesAndDir(...);
except
// Fehlerbehandlung
end;
end
else if (not IsDir) then
begin
try
Deletefile(..);
except
// Fehlerbehandlung
end;
end;
end;
Und RemoveFilesAndDir:
Delphi-Quellcode:
procedure TFtpBrowser.RemoveFilesAndDir(..);
begin
if (
not DeleteAll(AFile))
or (
not FFtp.RemoveDir(FDir.Text + AFile))
then
raise Exception.Create(...);
end;
So wird die Methode wesentlich übersichtlicher und man kann mit einem Blick erfassen, was passiert, an Hand der sprechenden Methodennamen.
Wobei noch zu überlegen wäre, ob man die Fehlerbehandlung nicht auch aus
DeleteFile nimmt. Dann kann der Anwender des Codes selber entscheiden, was bei einem Fehler passiert. Ich würde es jedenfalls so machen.
TriggerLogEvent wäre dann bei mir in einer eigenen Klasse, die man dem Programmierer mit an die Hand geben kann.
@Hansa: So meine ich das. Und wenn ein, zwei zeilen sinnvoll pro Funktion erscheinen, warum nicht.