Try - except - finally

[Furtbichler]

Zitat von idefix2:

Welchen Sinn es haben soll und inwieweit es "richtiger" sein soll, die finalen Aufräumarbeiten und die Fehlerbehandlung in zwei getrennte Prozeduren zu stecken, wobei eine die andere aufruft, erschliesst sich mir überhaupt nicht (ausser, mit dem Auftraggeber ist ein Zeilenhonorar vereinbart ).

Jede Methode soll genau eine Sache machen. Die Beschreibung der Methode sollte kein 'und' enthalten. Wenn doch, sollte man 2x hinschauen, ob man die Methode nicht aufsplitten kann. Kommentare (außer Rechtshinweise, Beschreibung von speziellen Algorithmen und vielleicht Klassenbeschreibungen) sind überflüssig, wenn man seinen Code so schreibt, das er -vorgelesen- genau das beschreibt, was er macht. Und das gelingt nur, wenn man die Methoden so aufdröselt, das sich die Beschreibung einer Methode in ihrem Namen widerspiegelt und sie keine Seiteneffekte hat. Für meine Begriffe ist das die einzige Möglichkeit, Programme zu schreiben, die auch für andere schnell begreifbar sind.

Du kannst natürlich auch alles in eine Methode packen, klar. Das mag bei einem einzeiligen Aufruf (und den einfachen Beispielen hier) noch funktionieren, aber das wird schnell unübersichtlich, wenn Aufräumarbeiten, Fehlerbehandlung usw komplexer werden. Es ist einfacher, sich an dieses oder ein ähnliches Pattern zu halten. Du kannst das natürlich sein lassen und alles in eine Methode packen, ganz wie es Dir gefällt.

[idefix2]

Zitat von Furtbichler:

Jede Methode soll genau eine Sache machen.

Natürlich. Nur gehören meiner Meinung nach prinzipiell Fehlerbehandlung UND Aufräumarbeiten zu der Sache. Wenn du einen Mittelwert bildest, schreibst du wohl auch nicht eine Prozedur zum Addieren und eine zweite für die anschliessende Division.
Es gibt einen Punkt, an dem das Aufteilen nicht mehr zu mehr Übersichtlichkeit, sondern zum Gegenteil führt.

[Furtbichler]

Zitat von idefix2:

Natürlich. Nur gehören meiner Meinung nach prinzipiell Fehlerbehandlung UND Aufräumarbeiten zu der Sache.

Vom Abstraktionsniveau her passt das einfach nicht. Das eine ist Resourcenschutzblock, das andere eine Fehlerbehandlung der Sicherungsschicht.

Zitat:

Wenn du einen Mittelwert bildest...

heißt die Methode vermutlich 'BildeMittelwert' und fertig.

Zitat:

Es gibt einen Punkt, an dem das Aufteilen nicht mehr zu mehr Übersichtlichkeit, sondern zum Gegenteil führt.

Den zu finden ist leicht: Wenn es lächerlich wird (wie bei deinem Beispiel), lässt man es.

Aber was ist hiermit:

Delphi-Quellcode:

data := Socket.SendCmd(IPCMD_RECV, OPTION_TRACERT or OPTION_FOOBAR or OPTION_BLAFASEL, 4912);
OtherComplicatedStuff.MagicFunction(data);

Versteht keine Sau. Aber das hier versteht jeder:

Delphi-Quellcode:

data := ReadDataFromSocket();
EncryptAndForwardToReceipient(data);

Die Implementierung der beiden Methoden interessiert ja nicht, wenn es nur ums Verständnis geht. Aber wer's wissen will:

Delphi-Quellcode:

Function TMyClass.ReadDataFromSocket() : TData;
Begin
  Result := Socket.SendCmd(IPCMD_RECV, OPTION_TRACERT or OPTION_FOOBAR or OPTION_BLAFASEL, 4912);
End;

Procedure TMyClass.EncryptAndForwardToReceipient(data : TData);
Begin
  EncryptAndForwardToReceipient(data);
End;

Ich habe den Code durch das (in deinen Augen lächerliche) Refactoring kommentiert, und zwar gänzlich ohne die negativen Effekte, die Kommentare sonst über die Zeit unbrauchbar machen (können). Jeder, der meinen Code liest, weiß sofort, was Sache ist. Und das, *obwohl* ich aus zwei Zeilen 10 gemacht habe

Aber wenn Du meinst, das Du es besser weißt: Bitte schön.

PS: Selbst eine Mittelwertbildung kann man refaktorisieren, wenn der Algorithmus zur Mittelwertbildung dem Leser vermutlich nicht bekannt ist (z.B. Schülern):

Delphi-Quellcode:

Function BildeMittelwert(Zahlenreihe : TZahlen) : Double;
Begin
  if Zahlenreihe.Anzahl=0 then
    Raise Exception.Create('Mittelwertbildung nicht möglich');
  else
    Result := SummeAllerZahlen(Zahlenreihe)/ Zahlenreihe.Anzahl;
End;

Auch wenn es in deinen Augen total unübersichtlich ist: Die Lesbarkeit ist erhöht . Ach, und falls mal wer die Summe aller Zahlen einer Zahlenreihe benötigt, hat man ihm gleich geholfen. Auch ein netter Nebeneffekt der unübersichtlichen Programmierung.

[Morphie]

Zitat von Furtbichler:

Delphi-Quellcode:

Procedure TMyClass.EncryptAndForwardToReceipient(data : TData);
Begin
  EncryptAndForwardToReceipient(data);
End;

Ist das nicht eine unendliche Rekursion?

[Mavarik]

Wie wär es mit

Delphi-Quellcode:

result := true;
try
  A := TFoo.Create;
  try
    ...
    if bla then
      Exit;     
    ...
  finally
    A.Free;
  end;
except
  result := false;
end;

Mavarik