Ich würde die Bedingungen in dem Test zu umkehren, wenn schlecht, dann deleteAndLog als das Beispiel unten. Dies verhindert das Verschachteln und bringt die Aktion in die Nähe des Tests.
%Vor%Ein möglicher Ansatz besteht darin, einzelne if-Anweisungen zu verwenden, die nach einer Bedingung suchen, die nicht zutrifft. Haben Sie eine Rückkehr für jede dieser Prüfungen. Dies verwandelt Ihre Methode in eine Sequenz von 'if' Blöcken anstelle von einem Nest.
Hier gibt es nicht viel nachzubessern, da Sie die drei Tests separat halten, da die Fehlermeldungen sich auf den durchgeführten Test beziehen. Sie können sich dafür entscheiden, dass die Testmethoden den Fehler zur Protokollierung zurückmelden, damit Sie sie nicht in der if / else-Struktur haben, was die Dinge einfacher machen könnte, da Sie dann einfach auf einen Fehler testen und die Datei löschen und löschen können .
Es sind die oben genannten Elemente, die mein Auge werfen. Hier ist eine Alternative, innerhalb des try {}
Sie können dies noch kürzer machen, indem Sie nach MoveToSafeFolder zurückkehren (Auch wenn Sie den finally-Block zurückgeben, wird er ausgeführt.) Dann müssen Sie keine leere Zeichenfolge zu errorMessage zuweisen, und Sie müssen dies nicht überprüfen ist errorString leer, bevor die Datei gelöscht und die Nachricht protokolliert wird). Ich habe es hier nicht gemacht, weil viele frühe Offensive finden, und ich würde in diesem Fall zustimmen, da die Ausführung des finally-Blocks nach der Rückkehr für viele Leute nicht intuitiv ist.
Hoffe, das hilft
%Vor%Wie wäre es damit?
%Vor%oder, noch besser, ... das:
%Vor%HINWEIS: Sie sollten generische Exception nicht fangen und verschlucken, ohne sie erneut auszulösen ...
Tags und Links coding-style refactoring