Home » Tutorials » Sonstiges » Refactoring oder Wie warte ich meinen Code?

Refactoring oder Wie warte ich meinen Code?

Das Umbenennen von Symbolen

Das Umbenennen von Symbolen meint nichts anderes, als dass wir die Namen von Funktionen, Prozeduren, Variablen, Konstanten etc. bequem durch wenige Klicks im gesamten Code ändern können. Der eine oder andere Leser mag sich jetzt fragen: Wo ist denn dann der Unterschied zur Suchen&Ersetzen-Option? Der Unterschied ist, dass das Refactoring eine gewisse „Intelligenz“ zeigt und nicht einfach jedes Vorkommen des Namen ersetzt, sondern nur diejenigen, die sich wirklich auf den angewählten Namen beziehen. Sehen wir uns dazu kurz den folgenden Quellcode an:

unit Unit_Main;

interface

  uses
    Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
    Dialogs;

  type
    TFormular_Main = class(TForm)
      procedure FormCreate(Sender: TObject);
      private
          MeineVariable: Integer;
    end;

  var
    Formular_Main: TFormular_Main;

implementation
  {$R *.dfm}

  procedure TFormular_Main.FormCreate(Sender: TObject);
  var
    MeineVariable: Integer;
  begin
    MeineVariable := 10;
    Self.Caption := IntToStr(MeineVariable);
  end;

end.

Wie man sehen kann, ist der Variablenname „MeineVariable“ an zwei verschiedenen Stellen im Code deklariert worden und hat entsprechend unterschiedliche Sichtbarkeitsbereiche. Nehmen wir nun an, wir möchten die Variable innerhalb des FormCreate-Ereignisses ändern. Dann könnten wir mit Sicherheit dreimal den Namen ändern. Oder wir nutzen das Refactoring. Dazu markieren wir den entsprechenden Variablennamen, klicken mit rechts und wählen unter „Refactoring“ einfach „Umbenennen Variable <Variablenname>“ aus.

Wir bekommen dann einen kleinen Dialog präsentiert.

Der Dialog ist selbsterklärend. Unter „Neuer Name“ tragen wir den gewünschten, neuen Namen ein. Das Feld „Vor Refactoring Referenzen anzeigen“ empfiehlt sich, angekreuzt zu lassen. Der Grund dafür ist Folgender: Wenn wir jetzt auf OK klicken, müssen wir nämlich nicht die Augen zumachen und beten, dass alles gut geht. Delphi zeigt uns dann vorher sämtliche Referenzen an. Also sämtliche Stellen in unserem Quellcode, wo wir auf genau diese Variable zugreifen. So können wir uns in Ruhe versichern, dass auch nur genau das gemacht wird, was wir wollen. Das empfiehlt sich gerade dann, wenn man noch nicht sicher sein kann, dass der Quellcode überhaupt läuft.
Weist der Code etwa fehlerhafte Strukturen auf, kann das Refactoring u.U. unvorhersehbare Seiteneffekte hervorrufen.
Eigentlich sollte sich automatisch ein kleines Fenster „Refactorings“ öffnen. Falls das nicht geschieht, gehen wir im Hauptmenu auf „Ansicht->Refactorings“.
Wenn wir bereit und zufrieden sind, drücken wir auf den kleinen, schicken Würfel und sehen uns das Ergebnis an. Dieses sollte z. B. so aussehen:

Man sieht: Die obere Variable wurde davon völlig unberührt gelassen.
Natürlich können wir, wenn wir unser zukünftiges Refactoring noch nicht ausgeführt haben, es auch aus der Liste löschen. Es empfiehlt sich aber, auch sämtliche bereits ausgeführten Refactorings in der Liste zu lassen. Delphi ermöglicht es nämlich, bereits ausgeführte Refactorings rückgängig zu machen.
Auch funktioniert das Prinzip, wie bereits erwähnt, nicht nur für Variablen. Wir können auch z. B. Prozeduren oder Typen umbenennen. Und natürlich ist dieses Beispiel auch recht einfach gewählt. Es ist nämlich durchaus möglich, dass wir plötzlich den Namen einer lokalen Variablen umbenennen möchten, die an hundert verschiedenen Stellen im Programm genutzt wird. Da wird der Sinn des Refactorings plötzlich ersichtlich…