Cnpack Unit-Cleaner

[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 von Glados:

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 von Glados:

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 von Glados:

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 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 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 //PALOFF hinter den Eintrag und gut is.

[Uwe Raabe]

Zitat von uligerhardt:

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

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