![]() |
Refactorings in Delphi?
Hallo! Ich habe mir gerade die Seite
![]() Wir haben folgenden Code:
Delphi-Quellcode:
Wir wählen die Berechnung
var
a, b, c: Integer; //... a := 2; b := 3; c := a + b;
Delphi-Quellcode:
mit der Maus aus, drücken auf einen Knopf und das Refactoring macht daraus:
a + b
Delphi-Quellcode:
D.h. das Refactoring hat aus der Berechnung
function MyUnit.MyClass.MySum(const a, b: Integer): Integer;
begin Result := a + b; end;
Delphi-Quellcode:
die Funktion MySum sowie ggf. eine neue Klasse und ggf. in einer neuen Unit erzeugt, natürlich aus unseren Vorgaben in einem Refactoring-Dialog.
a + b
Gibt es dieses Refactoring "FunktionAusBerechnung" für Delphi? Das ist natürlich nur ein einfaches Beispiel, aber bei größeren Berechnungen könnte man könnte sich dadurch eine Menge Tipparbeit ersparen, vor allem wenn die Berechnung "verschachtelt" ist. |
AW: Refactorings in Delphi?
Zitat:
|
AW: Refactorings in Delphi?
Refactorings sind sehr nützlich, wenn man weiß, wozu sie gut sind.
Die Refactoring-Tools sind sehr nützlich, wenn sie schneller gehen, als das manuelle Umschichten. Es gibt imho keine externen Refactoring-Tools für Delphi, weil es kaum einen Markt dafür gibt. Und vielleicht auch, weil die OTA (IDE-API) nicht dafür geeignet ist, aber letzteres ist nur eine Vermutung. |
AW: Refactorings in Delphi?
![]() |
AW: Refactorings in Delphi?
Zitat:
![]() Die eingebauten in Delphi finde ich durchaus nuetzlich, zumindest die zum Umbenennen von Variablen und Methoden sowie Extract Method und Search Unit verwende ich regelmaessig. |
AW: Refactorings in Delphi?
Extract Method würde ich auch gerne mehr nutzen, aber leider stolpert das immer wieder über die eigenen Füße und funktioniert nicht...
Das liegt wohl vor allem an neueren Features in Object Pascal, die ich eben sehr gerne nutze (nested types, generics, ...). Denn in Units, die nur Code nutzen, der auch vor Delphi 2009 kompilierbar wäre, funktioniert es in der Regel. Prinzipiell finde ich die eingebauten Refactorings schon für die meisten Fälle ausreichend, wenn sie denn funktionieren. Und die CnWizards haben auch noch ein paar Automatiken für die Codetransformation dabei (Zuweisung links rechts austauschen usw.), beides zusammen reicht mir gut. |
AW: Refactorings in Delphi?
Bei mir geht es erfahrungsgemäß schneller und zuverlässiger, einfach den Code zu copy-pasten und dann ggf. die Variablen mit dem Sync-Editor oder dem Umbenenn-Refactoring-Tool (z.B. in "Result") umzubenennen, wenn ich Code in eine Funktion auslagern will.
|
AW: Refactorings in Delphi?
Ausgehend von folgendem Code wurde testweise die Code-Auswahl
Delphi-Quellcode:
mit Delphis Refactoring-Methode bearbeitet:
c := a + b
Delphi-Quellcode:
Das in Delphi XE2 eingebaute "Methode extrahieren" macht daraus:
procedure TForm1.FormCreate(Sender: TObject);
var a, b, c: Integer; begin a := 2; b := 3; c := a + b; end;
Delphi-Quellcode:
D.h. es wird einfach und simpel die Anweisung
procedure TForm1.FormCreate(Sender: TObject);
var a, b: Integer; begin a := 2; b := 3; ExtractedMethod(a, b); end; procedure TForm1.ExtractedMethod(a: Integer; b: Integer); var c: Integer; begin c := a + b; end;
Delphi-Quellcode:
in eine Prozedur ausgelagert. Eine Parameter-Bearbeitung ist im Refactoring-Dialog nicht möglich. Die Rückgabe eines Ergebnisses ist nicht vorgesehen, da der Code selbst eine solche ja nicht benötigt. Streng nach Compiler-Logik eben.
c := a + b
Die erzeugte Prozedur sieht jedoch anders aus, wenn die Variable c NACH der Codeauswahl
Delphi-Quellcode:
noch verwendet wird:
c := a + b
Delphi-Quellcode:
In diesem Fall erzeugt das Delphi-Refactoring diesen Code:
procedure TForm1.FormCreate(Sender: TObject);
var a, b, c, d: Integer; begin a := 2; b := 3; c := a + b; d := a + b + c; end;
Delphi-Quellcode:
Mit dem var-Parameter berücksichtigt das Delphi-Refactoring intelligenterweise, dass die Variable c später noch verwendet wird.
procedure TForm1.FormCreate(Sender: TObject);
var a, b, c, d: Integer; begin a := 2; b := 3; ExtractedMethod(a, b, c); d := a + b + c; end; procedure TForm1.ExtractedMethod(a: Integer; b: Integer; var c: Integer); begin c := a + b; end; (ModelMaker Code Explorer setzt hier unnötigerweise 3 var-Parameter, obwohl an die Variablen a und b innerhalb der Prozedur ja gar nichts zugewiesen wird):
Delphi-Quellcode:
Das bedeutet also: Wenn man die Rückgabe eines Ergebnisses benötigt, kann man dies mit einem einfachen Trick erreichen. Man verwendet einfach die gewünschte Rückgabe-Variable in einer Dummy-Anweisung NACH der Code-Auswahl:
procedure TForm1.FormCreate(Sender: TObject);
var a, b, c, d: Integer; begin a := 2; b := 3; (*TODO: extracted code c := a + b; *) NewMethod(a, b, c); d := a + b + c; end; procedure TForm1.NewMethod(var a, b, c: Integer); begin c := a + b; end;
Delphi-Quellcode:
Das Delphi-Refactoring macht daraus:
procedure TForm1.FormCreate(Sender: TObject);
var a, b, c: Integer; begin a := 2; b := 3; c := a + b; c := c; // Dummy-Anweisung end;
Delphi-Quellcode:
procedure TForm1.FormCreate(Sender: TObject);
var a, b, c: Integer; begin a := 2; b := 3; ExtractedMethod(a, c, b); c := c; // Dummy-Anweisung end; procedure TForm1.ExtractedMethod(a: Integer; var c: Integer; b: Integer); begin c := a + b; end; |
AW: Refactorings in Delphi?
Zitat:
|
AW: Refactorings in Delphi?
Zitat:
Naja, meine Überlegung war, dass man die extrahierte Methode sowie den Aufruf dann an anderer Stelle verwenden würde. Aber ich habe mir jetzt ![]() |
Alle Zeitangaben in WEZ +1. Es ist jetzt 00:41 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz