UnitOptimizer

[dummzeuch]

Ich benutze derzeit 2x 4K (1x 32" mit 125% und 1x 28" mit 150% Skalierung) via Remote Desktop von einem Windows 10 System auf ein Windows 8.1 System. An letzterem hängen lokal 2x 1920x1200, aber das ist wohl irrelevant. Was nicht irrelevant ist, ist dass Windows 8.1 keine getrennten DPI per Monitor kennt und deshalb beide Monitore als 150% skaliert werden. Das hat "interessante" Effekte, sowhl auf die Delphi IDE als auch auf die Programme.

[stahli]

Ich habe mal etwas mit den Docking-Varianten herumgespielt, bin aber noch nicht richtig zufrieden.

Hat jemand vielleicht Zeit und Lust, da mal mit eine Lösung zu suchen?
Ich habe mal ein Video erstellt, in dem ich auf die Probleme eingehe: https://youtu.be/jVR6I76dA-A (8 Min)

Für den ungedockten Modus muss ich dann mal noch die Positionen auf anderen Monitoren klären und den Docking-Status am Monitorrand.

[jaenicke]

Dass das nicht angepinnte Fenster automatisch einklappt, ist kein Problem, sondern korrekt so. Wenn man es offen lassen möchte, muss man es anpinnen oder herausdocken. Das ist die bestehende Logik der IDE. Wichtig ist nur, dass der Status beibehalten wird, wenn man es erneut ausklappt ohne per Hotkey eine neue Suche zu starten.

Für Full-HD Bildschirme nimmt das permanente angepinnte Eindocken sicherlich viel Platz weg, aber erstens haben viele Entwickler Bildschirme mit höherer Auflösung und zweitens kann man es ja als Tab eindocken wie du auch gezeigt hast. Dann könnte der Hotkey schlicht zu dem Tab springen und das Fenster bliebe offen, wenn man das so möchte.

Das Andocken in voller Höhe wird nicht so gehen wie du dir das vorstellst, da es (meines Wissens) keine geschachtelten Tabs gibt. Ich habe das eben durch Manipulation der .dst Datei versucht, aber auch das klappte zunächst nicht. Ich vermute, dass es gar nicht geht. Diese Limitierung hat mich auch schon einmal gestört. Dafür hat Visual Studio beim Docken ja visuelle Dockmarkierungen, mit denen man besser als beim Delphi-Docking das Ziel bestimmen kann. Für Delphi gibt es dafür auch Komponenten (die allerdings nicht so besonders toll waren bei unseren letzten Experimenten damit), aber die IDE selbst kann das leider nicht.

Hier könnte ein Feature Request (falls er noch nicht existiert) durchaus Chancen haben, weil ich mir vorstellen kann, dass viele für ein solches geschachteltes Docking voten würden.

Ich selbst verwende MMX, das ohnehin mehr Platz braucht. Das habe ich links in fast voller Höhe eingedockt. Hier könnte ein Tab MMX, einer der Objektinspektor und einer deine Suche sein. Die Strukturansicht von Delphi kann man ausblenden (MMX reicht eigentlich) oder auch als Tab verwenden.

Das die Schnellsuche nach dem Eindocken die Größe verändert, muss ja im Code passieren, oder? Das sollte gedockt schlicht gar nicht passieren, denn die Größenanpassung übernimmt dabei soweit ich mich erinnere die IDE. Eigene Automatiken für den ungedockten Zustand sollte man dabei deaktivieren.

[stahli]

Danke Sebastian.

Die zwei "fehlenden" Optionen
- unpin-Formular offen lassen
- Tab mit optional übereinanderliegenden Inhalten
hätten halt schon perfekt gepasst für meine Bedürfnisse.
Man könnte das zwar mal vorschlagen aber kurzfristig wäre das sicherlich nicht umsetzbar und auch nur für neuere Delphis.

Bei der Schnellsuche habe ich keine Höhenanpassung vorgenommen.
Ich schätze, dass die IDE das "PageControl" in der Höhe entsprechend der originalen Höhe des ersten (links) eingedockten Formular ausrichtet (oder nach dem zuletzt hinzugefügten). Genauer habe ich das nicht untersucht.


Ich taste mich dann mal weiter vorwärts...

[jaenicke]

Zitat:

Zitat von stahli (Beitrag 1477822)

Man könnte das zwar mal vorschlagen aber kurzfristig wäre das sicherlich nicht umsetzbar und auch nur für neuere Delphis.

Das ist richtig, aber da aktuell das Aussehen der IDE ohnehin stark überarbeitet wurde und wird, ist die Chance aktuell höher als sonst. ;-)

[stahli]

Ich kann es mal versuchen. Aber das ist deutsch schon schwer zu erklären - englisch noch schwieriger (für mich). :oops:

[stahli]

Einen Teil habe ich geschafft.
Ungedockte Formulare kann man jetzt auf beliebigen Monitoren platzieren (und auch an Monitorränder anheften).
Eindocken geht natürlich auch noch.

Standardmäßig werden dockbare Formulare offenbar ungedockt nur auf dem Monitor geöffnet, auf dem die IDE geöffnet ist.
An verschiedenen Stellen speichere ich daher die Suchformular-Positionen in eine Ini bzw. stelle sie wieder daraus her.
Es ist etwas Frickelei, scheint aber stabil zu funktionieren.

[stahli]

Zitat:

Zitat von jaenicke (Beitrag 1477816)

Hier könnte ein Feature Request (falls er noch nicht existiert) durchaus Chancen haben, weil ich mir vorstellen kann, dass viele für ein solches geschachteltes Docking voten würden.

Ich habe mal einen Eintrag erstellt: https://quality.embarcadero.com/browse/RSP-31762
(Ob das verständlich ist, kann ich nicht garantieren.)

[stahli]

So, es ist vollbracht! :-)

Ok, zumindest so weit, dass es 3-4 Leute schon mal als Beta anschauen könnten.
Meldet Euch, wenn Ihr Interesse habt.

Voraussetzungen sind derzeit:
- immer aktuellste Delphi-Version
- akzeptieren des hellen Designs bei den Suchformularen
- akzeptieren von Codeveränderungen (möglichst kein Einsatz oder Akzeptanz trotz Versionierungssystem).

Ihr solltet aber unbedingt das Tool regelmäßig nutzen und ernsthaft an einem Einsatz des Tools interessiert (nicht nur mal neugierig) sein.
Es gibt sicherlich einige Dinge, die noch optimiert werden müssen aber es sollte jetzt so stabil sein, dass man damit schon ganz gut und sicher arbeiten kann.


Hier ein paar Videos:
installer ........ https://youtu.be/UUP-a3a4F5Q (3:14 min)
updates .......... https://youtu.be/F3Bx2NxQzoI (2:17 min)
setup ............ https://youtu.be/IXswa8cL7eY (13:11 min)
Beta-01 .......... https://youtu.be/z_Pwrmnvalk (55:29 min)

[stahli]

Hallo zusammen,

da bisher keinerlei Reaktion auf meine Mitteilung und Videos (15 Views auf die Zusammenfassung gab es) erfolgt ist, will ich hier mal pushen.
Vielleicht ist es ja auch etwas untergegangen auf Grund der Feiertage...

Gebt mir doch mal gern eine Rückmeldung, auch wenn sie skeptisch oder negativ ausfällt.
Haltet Ihr das Tool für unnötig oder habt Ihr das Anliegen nicht nachvollziehen können?
Seid Ihr zu skeptisch, was die Qualität und Stabilität betrifft?
Habt Ihr nicht die passenden Voraussetzungen für einen Beta-Test (falsches Delphi oder mögliche Probleme wegen einem Versionierungssystem)?

Ich arbeite jetzt mit Unterbrechungen 3 Jahre daran und hatte auf ein allgemeines Interesse gesetzt.
Zwar habe ich das natürlich für den eigenen Bedarf angefangen, der Umfang hat sich aber immer weiter ausgedehnt, da ich ein grundsätzliches Interesse an einem solchen Tool vorausgesetzt habe.

Gebt mir doch mal bitte eine Rückinfo. Das wäre lieb.




Und noch eine inhaltliche Frage.
Im Moment macht mir der Umgang mit den bedingten Compilierungen noch Probleme.
Zunächst einmal interpretiert der Formatierer derzeit die mehrfachen "end;" noch als Fehler und geht davon aus, dass die Unit nicht korrekt abgeschlossen ist.
Dazu muss ich ihm noch beibringen, dass er die IFDEF-ELSE-ENDIF-Blöcke jeweils getrennt voneinander bewerten bzw. hier nicht eindeutig abgeschlossene Blöcke tolerieren muss. Wird schwierig werden. :-(
Dann bin ich mir bezüglich der Einrückungen auch nicht sicher, was die beste Form wäre. Anbei mal einige Beispiele als Bild.
Ich würde die Variante 4 bevorzugen. Wie seht Ihr das?


Anbei mal noch der Quelltext, falls den mal jemand zurecht schieben möchte...

Delphi-Quellcode:

unit ifelseendif;

interface

implementation

uses
  System.SysUtils;

procedure hallo;
begin
  if true then
    begin
    {$IFDEF level1}
      Sleep(0);
    {$ELSE}
      if true then
        begin
        {$IFDEF level2}
          Sleep(1);
        end; //: ????????????????????????
        {$ELSE}
          Sleep(2);
        end; //: ????????????????????????
        {$ENDIF}
    {$ENDIF}
    end;
  Sleep(3);
end;

end.

[Moombas]

Nur mal als Hinweis: da ist ein end; zu viel oder eins muss durch ein else ersetzt werden.

[jaenicke]

Zitat:

Zitat von stahli (Beitrag 1480468)

Haltet Ihr das Tool für unnötig oder habt Ihr das Anliegen nicht nachvollziehen können?

Die Formatierung halte ich persönlich und rein subjektiv für unnötig bzw. der Lesbarkeit abträglich (die Meinung kennst du ja ;-)), von daher interessiert mich dieser Teil auch nicht. Ich nutze den integrierten Formatter und halte mich an die Standards, egal in welcher Sprache.

Interessieren würde mich die Suche. Da habe ich noch keine wirklich schöne Lösung gefunden, egal ob das Grep von den GExperts (das am ehesten an meine Vorstellungen herankommt) oder andere.

Zitat:

Zitat von stahli (Beitrag 1480468)

Habt Ihr nicht die passenden Voraussetzungen für einen Beta-Test (falsches Delphi oder mögliche Probleme wegen einem Versionierungssystem)?

Ich habe leider nicht genug Zeit um wirklich zu testen.

Und da ich dazu noch an der Formatierung nicht interessiert bin, bin ich als Tester eher nicht der richtige. Normal nutzen könnte ich die Suche natürlich (so oft brauche ich die aber gar nicht) und sagen was mir auffällt, aber mehr nicht.

[stahli]

@Moombas

Das Problem in dem Beispiel sind die Bereiche im $IFDEF.
Das war mal ein Beispiel, das ich irgendwo gefunden habe.
Wenn man das "end" einmal hinter das erste $ENDIF schreiben würde, wäre das wohl korrekt und nachvollziehbarer.
Der Compiler kommt aber so mit dem Code auch klar und der Formatierer sollt das entsprechend auch.
Deswegen suche ich auch für diese Form eine Lösung.

Die habe ich aber jetzt erst mal zurück gestellt, da sie wohl nicht wirklich als dringend erscheint.


@jaenicke

Ok, schade. Ich finde die Formatierung sehr hilfreich.

Die Suchfunktion kann ich Dir gern mal zu Verfügung stellen, aber würde noch etwas warten bis die Kinderkrankheiten raus sind.

Wäre das eigentliche Ziel des Optimizers was für Dich?
Schau mal in ein altes Video: https://youtu.be/q7X_gxcz12I?t=19 (3 Min)

Ich bin jetzt gerade dabei, die Funktion wieder neu aufzubauen...

[Moombas]

Zitat:

Zitat von stahli (Beitrag 1480545)

@Moombas

Das Problem in dem Beispiel sind die Bereiche im $IFDEF.
Das war mal ein Beispiel, das ich irgendwo gefunden habe.
Wenn man das "end" einmal hinter das erste $ENDIF schreiben würde, wäre das wohl korrekt und nachvollziehbarer.
Der Compiler kommt aber so mit dem Code auch klar und der Formatierer sollt das entsprechend auch.
Deswegen suche ich auch für diese Form eine Lösung.

Die habe ich aber jetzt erst mal zurück gestellt, da sie wohl nicht wirklich als dringend erscheint.

Was ich meine ist, wenn ich das erste "begin" markiere, müsste er das zugehörige "end;" markieren, was in deinem Beispiel bei mir das vorletzte ist (Siehe Anhang), da er das im Screenshot ausgegraute "end;" mit betrachtet.

[stahli]

Ich habe mit der bedingten Formatierung selbst keine Erfahrungen.
Man muss dazu die Bedingungen (Flags) festlegen, um dem Compiler zu sagen, welchen Block er compilieren soll.
In dem Beispiel entweder Sleep(1) oder Sleep(2).
Das Dumme in dem Beispiel ist, dass in beiden Bereichen ein "end;" steht.
Der Compiler nimmt dann das erste end oder das zweite end. Insofern ist für ihn alles ok.
Mein Formatierer kommt aber mit einer solchen (eher ungewöhnlichen) Konstellation noch nicht klar.
Dafür will ich mal noch eine Lösung finden. Aber später mal.

In dem Zusammenhang hätte mich auch ehr interessiert, welche Einrückungsvarianten Ihr bevorzugen würdet.

[dummzeuch]

Zitat:

Zitat von stahli (Beitrag 1480468)

da bisher keinerlei Reaktion auf meine Mitteilung und Videos (15 Views auf die Zusammenfassung gab es) erfolgt ist, will ich hier mal pushen.
Vielleicht ist es ja auch etwas untergegangen auf Grund der Feiertage...

Ohne Dich demotivieren zu wollen:
Ich lese Delphi Praxis quer. Ab und an sehe ich ein interessantes Thema, das ich mir dann genauer ansehe, dazu gehörte auch der UnitOptimizer.
Aber jedes mal auf Links zu den Videos klicken und sie mir anzuchauen ist mir zu lästig. Das habe ich zwei-, dreimal gemacht, aber der Nutzen steht für mich in keinem Verhältnis zum Aufwand.

[stahli]

Danke Dir trotzdem.

Ja, mit dem Aufwand hätte ich so auch nicht gerechnet, wollte aber dann trotzdem weiter dran bleiben.

Aber die Klassen- und Interfacevervollständigung war genau das, was mir immer bei der Arbeit gefehlt hat.
Die anderen Dinge waren dann eher Beiwerk u d haben sich zusätzlich ergeben.

Videos finde ich persönlich immer die beste Art, etwas zu erklären oder zu zeigen.
Ich wüsste nicht, wie ich die Zwischenstände besser und schneller vermitteln könnte.

[Moombas]

Hi Stahli,

zur Einrückungsvariante, die ich bevorzuge:

Delphi-Quellcode:

procedure hallo;
begin
  if true then
  begin
    Sleep(0);
    if true then
    begin
      Sleep(1);
    end;
  end;

  if true then
  begin
    Sleep(1);
  end else
  begin
    Sleep(2);
  end; 

  if true then
  begin
    Sleep(1);
  end else if true then
  begin
    Sleep(2);
  end; 

  if (true) or
     (true) then
  begin
    Sleep(1);
  end; 

  //...

  Sleep(3);
end;

[ringli]

Zitat:

Zitat von stahli (Beitrag 1480468)

Habt Ihr nicht die passenden Voraussetzungen für einen Beta-Test (falsches Delphi oder mögliche Probleme wegen einem Versionierungssystem)?

Grundsätzlich bin ich zwar an dem Tool interessiert (vorwiegend Formatierer und Suche) und würde es mir auch mal ansehen wollen. Allerdings bin ich nur Hobbyprogrammierer und von daher nicht regelmäßig dabei um das Plugin wirklich ausgiebig testen zu können.

Vorschlag: Stelle hier doch einfach mal eine Testversion zum Download bereit. Vielleicht schauen sich das Plugin dann ein paar Leute an die vielleicht nicht unbedingt deinen Vorstellungen eines Betatesters entsprechen aber durchaus vielleicht das ein oder andere anzumerken haben.

[stahli]

@Moombas

Sorry, da hatte ich mich unklar ausgedrückt.
Mir ging es jetzt um die Einrückungen im Zusammenhang mit den bedingten Kompilierungen.
Also die Blöcke

Delphi-Quellcode:

        {$IFDEF level2}
          ...
        {$ELSE}
          ...
        {$ENDIF}

und darin enthaltenem Code.


@ringli

Vielen Dank, das freut mich schon mal.
Das werde ich auch gern später so machen, im Moment würde ich mich aber lieber auf einen "kleinen harten Kern" begrenzen, da noch einiges zu tun ist.
Auch Probleme sind noch nicht ganz ausgeschlossen. (Nicht, dass ein gesamtes Projekt zerschossenen wird, aber dass mal eine Unit noch nicht ordentlich formatiert werden könnte.)
Ich muss dann in der IDE auch verschiedene Optionen bereitstellen, da die Vorstellungen und Wünsche bezüglich der Formatierung schon sehr unterschiedlich sind.
Also für einen kompletten offenen Test ist es leider noch zu früh.

[jaenicke]

Zitat:

Zitat von stahli (Beitrag 1480591)

Auch Probleme sind noch nicht ganz ausgeschlossen. (Nicht, dass ein gesamtes Projekt zerschossenen wird, aber dass mal eine Unit noch nicht ordentlich formatiert werden könnte.)

Wer kein Versionskontrollsystem wie Git verwendet ist selbst schuld. ;-)

[stahli]

Ja sicherlich. Aber ich möchte ja kein Ärgernis verursachen.
Das Tool soll ja helfen und keinen zusätzlichen Aufwand bringen.

Insofern muss es erst richtig ausgereift sein, ehe ich es auf die Allgemeinheit loslasse.

Derzeit muss man eben noch damit rechnen, dass sich doch mal noch hier und da Probleme ergeben können.
Wer das in Kauf nehmen will und grundsätzliche Idee mit unterstützen will, kann sich aber gern melden.

[stahli]

Ich will mal wieder einen aktuellen Stand vorstellen: https://youtu.be/azP8w6g0i18

Zwar war ich schon mal etwa so weit, habe aber nochmal auf einen komplett anderen Ansatz umgestellt, da der vorherige mit auskommentiertem Code bei den ganzen Umsortierungen und Vervollständigungen nicht gut zurecht kam. Jetzt sollte ich da besser weiter kommen.

Die Suche läuft jetzt in einem Task, so dass man durch laufende Änderungen des Suchtextes live die alte laufende Suche abbrechen und eine neue Suche starten kann.

Ich setze den Optimizer jetzt selbst schon real bei der Arbeit ein und anstehende Erweiterungen lassen sich jetzt regelmäßig ganz gut realisieren. Ich hoffe, dass das auch so weiter geht. :-)

[bernhard_LA]

youtube zeigt mir das Video nicht in der Übersicht an - der direkte Link von oben geht , seltsam :evil:

könntest du im Unit optimizer noch eine einmheitliche Groß-Klein Schreibung vür alle Funktinen und Variablen einbauen ?

[stahli]

Das Video steht auf "nicht gelistet", ist also öffentlich aber man braucht den Link.
(ist mehr was für zwischendurch und unter uns)

Groß- und Kleinschreibung von Schlüsselwörtern kann ich problemlos regeln (auch erstes Zeichen groß, Rest klein).
Aber mal später, wenn es dann an diverse Optionen geht.

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.
Um Änderungen dann auch im Code vorzunehmen, müsste dann ein echtes Refactoring angestoßen werden. Ich weiß nicht ob das geht und ob das Sinn macht.

[dummzeuch]

Zitat:

Zitat von stahli (Beitrag 1494747)

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:

Zitat von dummzeuch (Beitrag 1494756)

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:

Zitat von Uwe Raabe (Beitrag 1494763)

Zitat:

Zitat von dummzeuch (Beitrag 1494756)

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:

Zitat von stahli (Beitrag 1494783)

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:

Zitat von stahli (Beitrag 1494783)

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 :D) 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?

[stahli]

Jetzt werden auch innerhalb der IDE Interfaces in anderen Units gefunden und verarbeitet. :-)

Anbei mal ein Auszug, wie eine vorher recht wüste Unit nach dem Optimieren aussieht.

(Die Performance passt noch nicht, aber da kann ich sicher noch etwas rausholen.)

[dummzeuch]

Zitat:

Zitat von jaenicke (Beitrag 1494797)

Zitat:

Zitat von stahli (Beitrag 1494783)

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.

[dummzeuch]

Zitat:

Zitat von stahli (Beitrag 1494801)

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.

[stahli]

Ok danke. Das muss ich dann mal später genauer untersuchen wenn es mir überhaupt mal gelingen sollte, ein Refactoring über die OTA anzustoßen.

In dem Fall könnte ich über eine eine einzelne Anweisung wohl innerhalb eines Projektes gleich zeitig ein Property eines Interfaces umbenennen incl. automatisch Getter und Stter anpassen und die Änderung auch in alle benutzenden Klassen durchschleifen (dort auch incl. privatem Feld).
Wenn ich ein Refactoring grundsätzlich aufrufen kann, dann sollte das so machbar sein.

Ob die Anpassung dann auch in einem anderen externen Projeklt möglich ist, wäre dann eben nochmal zusätzlich zu klären (wenn die Anforderung überhaupt als interessant erachtet würde).


PS: Zu meiner Entschuldigung ... wenn ich in der Woche tagsüber schreibe habe ich i.d.R. kein Delphi verfügbar und jetzt am Wochenende versuche ich mich erst mal um die aktuelleren Dinge zu kümmern. Daher kommen sicher manchmal etwas komische Fragen von mir. :oops:

[stahli]

Der Umzug nach D.11 und Anpassung des Installers gingen bis hierher recht problemlos. :-)

[stahli]

Kleiner Nebeneffekt...

Zwar muss man die automatisch erzeugten Units natürlich nicht formatieren, aber mir gefällt das so auf jeden Fall besser und ich finde es übersichtlicher. :-)

[jaenicke]

Zitat:

Zitat von stahli (Beitrag 1495652)

Zwar muss man die automatisch erzeugten Units natürlich nicht formatieren, aber mir gefällt das so auf jeden Fall besser und ich finde es übersichtlicher. :-)

Da der dort verwendete Parser ein wenig... eigenwillig... um nicht zu sagen fehlerhaft... ist, würde ich zumindest in der Projektdatei auf eigene Formatierungen verzichten...