Cnpack Unit-Cleaner

[Glados]

Der Unit-Cleaner ist schon recht interessant.
Dass ich Einträge markiert mit "indirekt abhängig" nicht ankreuzen sollte, ist klar.

Was sind aber diese "mit initialization"-Einträge? Kann man die ankreuzen und entfernen lassen? Bis jetzt habe ich noch keine Probleme bemerkt aber ich habe noch circa 50 solcher Einträge, die ich gerne loswerden möchte.

[Uwe Raabe]

Wenn eine Unit mit initialization Teil nirgendwo im Projekt mehr verwendet wird, dann der der initialization Teil auch nie ausgeführt. Solange die Unit also noch in anderen Units oder im Projekt explizit aufgeführt ist, kann sie in den Units, die sie nicht direkt benötigen, bedenkenlos entfernt werden.

[Glados]

Ich merke gerade, dass wenn man initialization-Einträge entfernt, sie oft auch einfach automatisch wieder in die uses and Ende geschrieben werden.
Ist also idiotensicher.

[uligerhardt]

Zitat:

Zitat von Glados (Beitrag 1382081)

Ich merke gerade, dass wenn man initialization-Einträge entfernt, sie oft auch einfach automatisch wieder in die uses and Ende geschrieben werden.
Ist also idiotensicher.

Ich vermute, du meinst, dass Delphi in Pascaldateien, zu denen eine DFM gehört, einige Units automatisch hinzufügt? Das hat aber nichts mit initialization zu tun, sondern damit, dass auf der Form eine Komponente pappt, die die Unit braucht. Also nix idiotensicher. :mrgreen:

[Glados]

Und wenn ich was lösche was wichtig ist, dann dürfte ich doch nicht mehr kompilieren können oder?

[nahpets]

Ist doch ganz einfach:

Alles in den Usesteilen einer Unit auskommentieren, Strg+F9 kompilieren.

Die IDE fügt ein, was benötigt wird.

Gibt es noch Fehler, schaut man im Auskommentierten, was da drin ist, was nicht neu eingefügt wurde. (Es sei denn, man weiß aufgrund der Fehlermeldung, was fehlt. Das trage man dann direkt ein.)

Wurde fehlerfrei kompiliert, wird das Auskommentierte gelöscht.

Geht gut, einfach und schnell.

[Glados]

Zitat:

Die IDE fügt ein, was benötigt wird.

Wenn das auch mit eigenen Units funktionieren wäre, wäre das ein Traum.

[nahpets]

Die IDE schaut, was benötigt wird und nicht wer es geschrieben hat.

Die Herkunft einer benötigten Unit ist wurscht.

Wenn Du eine Komponente schreibst und die benutzt, in dem Du sie auf ein Formular pappst, dann fügt die IDE die Unit unter uses ein, genauso wie bei Komponenten, die mit der IDE geliefert wurden oder die zu irgendeiner später installierten Fremdkomponente gehören.

Vielleicht ja einfach mal ausprobieren.

[Glados]

Nochmal:
Wenn das auch mit eigenen Units (keine Komponente) funktionieren wäre, wäre das ein Traum. :stupid:

[nahpets]

Es funktioniert auch nicht mit nichteigenen Units, die keine Komponenten enthalten ;-)

Die Herkunft ist egal.

[Glados]

---

[stahli]

@nahpets

Bei D7 ging das finden von Units m.E. noch zuverlässiger (dass die IDE fehlende immer ergänzt ist mir aber gerade neu - nur bei Ctrl+F9 oder auch bei F9?).

Mit XE3 nicht mehr. Da gibt es Ctrl+Shift+A zum Finden einer Unit, die eine bestimmte Klasse implementiert.
Meist funktioniert das auch nicht. Dann suche ich die Klasse oder Funktion in der Hilfe und hoffe, dort etwas zu finden oder ich suche die Klasse bzw. Funktion in im Projekt (wenn sie schon mal verwendet ist) und springe dann mit Ctrl+Click zur Deklaration.

Delphi-IDE halt...

[nahpets]

Das wäre dann aber ein massiver Rückschritt.

Eigentlich mache ich mir über die genutzten Units nie Gedanken.

Zu allem, was ich so auf ein Formular pappe, wird von der IDE beim Kompilieren (egal ob F9 oder Ctrl+F9) alles Fehlende eingefügt.

Habe ich im Quelltext irgendwelche Verweise auf andere Formulare, Datenmodule ..., die schon irgendwo im Projekt eingebunden sind, dann werde ich ggfls. gefragt, ob sie noch in eine Unit eingebunden werden sollen. Das passiert halt schonmal, wenn man aus Form1 auf Form2 verweist ...

Was nie automatisch eingebunden wird sind StrUtils, Math ..., also die Units, die nur reine Funktionssammlungen sind.

Grob kann man wohl sagen: Automatisch ergänzt wird alles, was über die in die IDE eingebundenen Packages irgendwie referenziert und genutzt wird.
Mit Nachfrage wird eingebunden, was ins Projekt (die .dpr) eingebunden wurde.

[uligerhardt]

Zitat:

Zitat von nahpets (Beitrag 1382117)

Mit Nachfrage wird eingebunden, was ins Projekt (die .dpr) eingebunden wurde.

Aber auch nur, wenn's irgendwie mit ner DFM verbandelt ist. Reine Pascal-Units ohne DFM muss man (also ich zumindest :mrgreen:) manuell einbinden.

[stahli]

Deswegen meinte Glados, dass es wünschenswert wäre, dass die IDE auch Klassen und Funktionen findet, die nicht registrierte Komponenten in der Komponentenpalette sind.

[nahpets]

@uligerhardt: Das war mir so noch nicht bewusst.
Bisserl nachdenk ... ja, Du hast recht.

@stahli Ja, der Wunsch ist nachvollziehbar. Bei Sachen, die man nicht regelmäßig nutzt und deren Herkunft man nicht so genau kennt, kann man da schonmal etwas mehr Suchaufwand benötigen, bis man das Richtige gefunden und eingebunden hat.

[freimatz]

Zitat:

Zitat von nahpets (Beitrag 1382085)

Ist doch ganz einfach:

Alles in den Usesteilen einer Unit auskommentieren, Strg+F9 kompilieren.

Die IDE fügt ein, was benötigt wird.

Gibt es noch Fehler, schaut man im Auskommentierten, was da drin ist, was nicht neu eingefügt wurde. (Es sei denn, man weiß aufgrund der Fehlermeldung, was fehlt. Das trage man dann direkt ein.)

Wurde fehlerfrei kompiliert, wird das Auskommentierte gelöscht.

Geht gut, einfach und schnell.

Das gilt nur bei einfachen Projekten. Habe gerade mal eine Zeile gelöscht und compiliert. Das dauert dann gefühlt 15 Sekunden. Das gilt dann nur für ein uses, bei uns sind 20 uses keine Seltenheit. Ich finde den cleaner extrem nützlich.

Die Dateien im initialization Teil zu löschen finde ich extrem gefährlich. Das es compiliert heißt nochlange nicht, dass auch alles noch so funktioniert. Wie Uwe schon schrieb:

Zitat:

Zitat von Uwe Raabe (Beitrag 1382079)

Wenn eine Unit mit initialization Teil nirgendwo im Projekt mehr verwendet wird, dann der der initialization Teil auch nie ausgeführt. Solange die Unit also noch in anderen Units oder im Projekt explizit aufgeführt ist, kann sie in den Units, die sie nicht direkt benötigen, bedenkenlos entfernt werden.

[Glados]

Zitat:

Die Dateien im initialization Teil zu löschen finde ich extrem gefährlich.

Ich lösche ja keine Dateien. Sondern der Cleaner schreibt in Klammern nur "mit initialization".

Zitat:

Wie Uwe schon schrieb:

Kann man das einfacher erklären?

Und Units mit initialization und finalialization Teil habe ich etwa eine Hand voll.

[Uwe Raabe]

Zitat:

Zitat von Glados (Beitrag 1382136)

Kann man das einfacher erklären?

Nun, der Initialization-Teil einer Unit wird ja nur dann ausgeführt, wenn die Unit auch im Projekt mit eingelinkt ist. Taucht die Unit nirgendwo in einer Uses-Anweisung auf, dann wird sie auch nicht eingelinkt und somit der Initialization-Teil auch nicht ausgeführt. Will man dies trotzdem, dann muss man die Unit irgendwo in einer uses-Anweisung aufführen, auch wenn das syntaktisch zum compilieren nicht nötig wäre.

Beispiel:

Delphi-Quellcode:

unit A;

interface

type
  TMyAbstractClass = class
  public
    procedure DoSomething; virtual; abstract;
  end;

var
  MyInstance: TMyAbstractClass = nil;

implementation

end.

Delphi-Quellcode:

unit B;

interface

implementation

uses
  A;

type
  TMyClass = class(TMyAbstractClass)
  public
    procedure DoSomething; override;
  end;

procedure TMyClass.DoSomething;
begin
 // mach irgendwas
end;

initialization
  MyInstance := TMyClass.Create;
finalization
  MyInstance.Free;
  MyInstance := nil;
end;

Unit B hat einen leeren interface-Teil, kann also nirgendwo zum compilieren gebraucht werden. Trotzdem funktioniert das Programm nicht, wenn Unit B nicht trotzdem irgendwo in der uses-Anweisung steht.

[Glados]

Jetzt habe ich es auch verstanden.
Dann habe ich ja nochmal Glück gehabt denn ich kann 1. noch hinweis- und fehlerfrei kompilieren und 2. habe ich keine Zugriffsverletzungen oder ähnliches.

[Uwe Raabe]

Zitat:

Zitat von Glados (Beitrag 1382141)

Dann habe ich ja nochmal Glück gehabt denn ich kann 1. noch hinweis- und fehlerfrei kompilieren und 2. habe ich keine Zugriffsverletzungen oder ähnliches.

Nun ist Glück aber kein anerkanntes Programmier-Paradigma - obwohl offenbar weit verbreitet.

[Glados]

Letzte Frag zu

Zitat:

Trotzdem funktioniert das Programm nicht, wenn Unit B nicht trotzdem irgendwo in der uses-Anweisung steht.

Was genau heißt "funktioniert nicht" in diesem Fall? Würde es eine AV o.ä. geben oder erst gar nicht kompilieren?

Zitat:

bei uns sind 20 uses keine Seltenheit. Ich finde den cleaner extrem nützlich.

Da bin ich beruhigt denn es gibt Units da habe ich auch 10 bis XY Uses-Einträge. Ich versuche Units zwar immer sauber zu halten, sodass man sie auch in anderen Projekten verwenden kann aber bei manchen Codeteilen ist das nicht möglich.

[Uwe Raabe]

Zitat:

Zitat von Glados (Beitrag 1382143)

Was genau heißt "funktioniert nicht" in diesem Fall? Würde es eine AV o.ä. geben oder erst gar nicht kompilieren?

In diesem Fall würde beim Zugriff von

Delphi-Quellcode:

MyInstance

eventuell eine Exception ausgelöst. Kompilieren würde es trotzdem. Was im konkreten Einzelfall passiert, wenn eine solche Unit fehlt, kann man pauschal nicht sagen. Manchmal ist einfach nur eine bestimmte Funktionalität nicht vorhanden (im obigen Beispiel würde man dafür auf

Delphi-Quellcode:

MyInstance <> nil

testen und gegebenenfalls einen Menüpunkt ausblenden). Programm kompiliert, läuft, tut aber trotzdem nicht was es soll.

[uligerhardt]

Wir erledigen unsere uses-Pflege mit dem Pascal Analyzer (PAL) von Peganza. Der entfernt zwar nix automatisch, aber ab und zu mal die Liste manuell abzuarbeiten überfordert nicht. Mittlerweile gibt's auch eine Lite-Version.

PAL bringt (zumindest bei den überflüssigen bzw. fehlplazierten uses-Einträgen) kaum false positives, und wenn doch, schreibt man

Delphi-Quellcode:

//PALOFF

hinter den Eintrag und gut is.

[Uwe Raabe]

Zitat:

Zitat von uligerhardt (Beitrag 1382159)

PAL bringt (zumindest bei den überflüssigen bzw. fehlplazierten uses-Einträgen) kaum false positives, und wenn doch, schreibt man

Delphi-Quellcode:

//PALOFF

hinter den Eintrag und gut is.

Parallel dazu wäre an Bugreport an Peganza sicher auch hilfreich :wink:

[uligerhardt]

Zitat:

Zitat von Uwe Raabe (Beitrag 1382161)

Parallel dazu wäre an Bugreport an Peganza sicher auch hilfreich :wink:

Keine Sorge, ich decke den armen Christer schon ordentlich mit Bugreports ein. :mrgreen:
Oft ist's aber halt so, dass sich solche Probleme nicht gut aus dem Gesamtprojekt extrahieren lassen.