UnitOptimizer

[dummzeuch]

Zitat von stahli:

Für Variablen-, Typen- und Methodenbezeichnungen wäre das technisch bei den Deklarationen möglich, aber das sehe ich kritisch. Wenn irgendwo z.B. "FirstName" definiert wird, sollte so ein Tool das natürlich nicht von sich aus in der Groß- und Kleinschreibung ändern.

Definitiv nicht!

Was ginge, ist dass ein Tool sich die erste Schreibweise (=Deklaration) in einer Unit merkt und die dann überall verwendet. Allerdings sollte das abschaltbar sein, denn es kann auch gewaltig nerven, wenn es lokale Variablen mit einer anderen Schreibweise als z.B. Felder eines Records oder Properties einer Klasse gibt.

[stahli]

Um alle Verwendungen von Bezeichnern genau an die Groß- und Kleinschreibung wie bei der Deklaration anzupassen, bräuchte man definitiv ein richtiges Refactoring (das also die Bezüge nach der Kompilierung kennt).

Das habe ich bisher nicht. Ich nutze nur den reinen Klartext.

Aber ich würde gern später man auch Umbenennungen ermöglichen wie z.B:

Delphi-Quellcode:

IPerson = interface
  function  _get_first_name
  procedure _set_first_name(aValue: String);
  property first_name: String read _get_firstname write _set_first_name; rn: FirstName:String[100]
end;

Durch das "rn: FirstName:String[100]" würde das Property direkt im Interface umbenannt (incl. Getter und Setter und Typ) und dann auch in allen Klassen, die das Interface benutzen (dort dann auch die privaten Felder). Das wäre dann auch in anderen Projekten realisierbar, die dieses Interface benutzen.
In den Deklarationen könnte ich das ziemlich Problemlos machen, aber um das auch im benutzenden Code durchgehend anzupassen, müsste ich das Refactoring vom Delphi aufrufen. Ich hoffe, dass das dann geht, habe mich aber damit noch nicht befasst.


PS: Statt dieser "Kürzel-Anweisungen" könnte ich ggf. auch ein Formular aufrufen, das die Deklarationsstruktur der betreffenden Unit (als Objekte oder Baum) anzeigt und dort Änderungen ermöglicht (einfügen, umbenennen, löschen).

[Uwe Raabe]

Zitat von dummzeuch:

Was ginge, ist dass ein Tool sich die erste Schreibweise (=Deklaration) in einer Unit merkt und die dann überall verwendet.

So wie der integrierte Delphi Formatter?

[dummzeuch]

Zitat von Uwe Raabe:

Zitat von dummzeuch:

Was ginge, ist dass ein Tool sich die erste Schreibweise (=Deklaration) in einer Unit merkt und die dann überall verwendet.

So wie der integrierte Delphi Formatter?

Oder der in GExperts, ja.

Was mich daran erinnert, dass ich mal schauen wollte, ob einige der Bugs im Delphi Formatter (ich meine ich hätte 3 gemeldet) endlich behoben wurden.

[stahli]

Die Optionen kannte ich so jetzt gar nicht.

Aber das würde nicht auf Klassenmember o.ä. angewendet - oder?
(Ich kann jetzt gar nicht konkret sagen, wann Delphi Schreibweisen korrigiert und wann nicht.)
... Panel1.font.name -> Panel1.Font.Name

Dazu müsste ja immer die Deklaration gesucht und die dortige Schreibweise abgeglichen werden.
Nach meinem Verständnis muss dazu das Projekt kompiliert sein und eine Verbindung zu den Codeteilen (Unit X, Zeile Y, Zeichen Xvon ... Xbis) vorliegen. Richtig?

[Uwe Raabe]

Zitat von stahli:

Dazu müsste ja immer die Deklaration gesucht und die dortige Schreibweise abgeglichen werden.

Nein, da steht ja nur As first occurence und nicht As declaration und der Formatter arbeitet ja nicht wie ein Compiler. Ich glaube auch nicht, dass das dateiübergreifend funktioniert, denn der Formatter bekommt ja entweder den markierten Code-Abschnitt oder die gesamte Unit. Aber das kann man ja gerne mal durch ausprobieren herausfinden.

[jaenicke]

Zitat von stahli:

Nach meinem Verständnis muss dazu das Projekt kompiliert sein und eine Verbindung zu den Codeteilen (Unit X, Zeile Y, Zeichen Xvon ... Xbis) vorliegen. Richtig?

So schlau ist der Formatter nicht, aber das braucht er auch gar nicht zu sein. Denn mir fällt kein einziges Beispiel ein, in dem es sinnvoll ist, ein ganzes Wort kontextabhängig anders zu schreiben.

Ich verwende ja den Formatter und bis jetzt war ich mit der Formatierung in Standardeinstellungen sehr zufrieden, wobei ohnehin nur sehr wenig überhaupt noch geändert wird, da ich ohnehin direkt "normal" schreibe. Das schließt auch Groß- und Kleinschreibung ein. Hier im Forum schreibe ich ja auch (meistens hoffe ich ) korrektes Deutsch.

Bei fremden Quelltexten ist es durchaus angenehm, wenn ich nur die ersten Vorkommnisse korrigieren muss und die Groß- und Kleinschreibung danach automatisch angeglichen wird.

[stahli]

Mit meiner Frage meinte ich eher das Refactoring.

Dazu muss der Compiler die verschiedenen binären Objekte (z.B. eine globale Variable "X") kennen und alle Codestellen in allen Units, die diese Variable benutzen.
Wenn ich ein Refactoring aufrufe und "X" in "XX" umbenenne, dürfte das nicht möglich sein, wenn das Projekt nicht kompiliert bzw. kompilierbar ist...
Ich denke mal, das dürfte so richtig sein.

Jetzt eine (vielleicht zu akademische?) Frage:

Ich hatte die Vorstellung, Umbenennungen in einem Interface auch in anderen Units (auch anderen Projekten) nachzuholen. Macht das überhaupt Sinn und wie würde man das aktuell händeln?

Mal ein Beispiel:

Ich habe zentral abgelegt eine Unit mit einem Interface und einer Property X.
Das Interface wird in 2 Projektgruppen verwendet.
Projektgruppe1 hatte es eingeführt. In Projektgruppe2 wurde die zentrale (selbe) Unit auch eingebunden und das Interface für neue Klassen benutzt.
In Projektgruppe2 werden neue Methoden und Properties in dem Interface deklariert. In Projektgruppe1 brauche ich nur meine Klassenvervollständigung starten und alle neuen Methoden und Properties werden in allen Klassen, die das Interface verwenden automatisch ergänzt (zumindest als Templates).

Soweit kein Problem, das sollte so funktionieren.


Jetzt die vermutlich akademische Frage:

Wenn ich innerhalb der Projektgruppe1 das Property X umbenenne in XX (und das in allen Klassen der Projektgruppe1 über ein Refactoring angepasst wird - sofern mir das irgendwann gelingen sollte), wie würde man in der Projektgruppe2 damit umgehen? Bzw. wie würde man das tun ohne mein Tool?

Die Projektgruppe2 wäre ja jetzt nicht mehr kompilierbar, da dort die Klassen (mit Property X) nicht der Deklaration des aktuellen Interfaces (mit Property XX) entsprechen. Ein Refactoring dürfte in dem Moment generell nicht mehr möglich sein.

Man wird also alle Codestellen suchen und händisch anpassen müssen. Mein Optimizer könnte dies ggf. in den Deklarationen und innerhalb der Getter und Setter automatisch übernehmen, nicht aber für die bisherigen Verwendungen von .X (die jetzt .XX heißen müssen) außerhalb der Getter und Setter.

Das ist sicherlich auch kein Standardfall, dass man Properties von Interfaces umbenennt, die in unterschiedlichen Projekten verwendet werden aber hatte jemand schon mal so etwas bzw. eine Meinung bzw. Umgang dafür?

[dummzeuch]

Zitat von stahli:

Mit meiner Frage meinte ich eher das Refactoring.

Dazu muss der Compiler die verschiedenen binären Objekte (z.B. eine globale Variable "X") kennen und alle Codestellen in allen Units, die diese Variable benutzen.
Wenn ich ein Refactoring aufrufe und "X" in "XX" umbenenne, dürfte das nicht möglich sein, wenn das Projekt nicht kompiliert bzw. kompilierbar ist...
Ich denke mal, das dürfte so richtig sein.

Doch, das funktioniert durchaus, wenn auch in Grenzen:

Delphi-Quellcode:

function bla(_x: Integer): Extended;
begin
  // fiktive Formel kopiert von woanders, wo x verwendet wurde:
  Result := x * 5 - pi;
end;

In dem Fall kann man problemlos die Variable x in _x umbenennen lassen, obwohl der Code wegen der nicht deklarierten Variablen x nicht compiliert.

[dummzeuch]

Zitat von jaenicke:

Zitat von stahli:

Nach meinem Verständnis muss dazu das Projekt kompiliert sein und eine Verbindung zu den Codeteilen (Unit X, Zeile Y, Zeichen Xvon ... Xbis) vorliegen. Richtig?

So schlau ist der Formatter nicht, aber das braucht er auch gar nicht zu sein. Denn mir fällt kein einziges Beispiel ein, in dem es sinnvoll ist, ein ganzes Wort kontextabhängig anders zu schreiben.

Spaßig ist es aber bei einzelnen Buchstaben:

x vs X und y vs Y -> gibt es mehrfach in unterschiedlichen Schreibeweisen in der RTL/VCL und diversen Bibliotheken

i vs I -> will man nie groß schreiben
l vs L -> will man nie klein schreiben
o vs O -> will man nie groß schreiben

Und dann gibt es da noch message vs. Message und natürlich private vs. Private und ähnliches, was aber wohl seltener vorkommt.