Warnungen und Hints

[Ralle1]

Ich habe ein großes Delphi-Projekt vor mir, bei dem über Jahre kein Wert auf Warnungen und Hints gelegt wurde. Schaltet man diese bei Projekterzeugung ein, kommt man in der Summe auf über 10.000 Warnungen und Hinweise.

Ich plane nun, sämtlichen Bestandscode per Definition zu Legacy Code zu erklären und Warnungen/Hints zu ignorieren. Sämtliche pas Dateien bekommen in die 1. Zeile ein {$WARNINGS OFF} {$HINTS OFF} und in die letzte Zeile {$WARNINGS ON} {$HINTS ON}. Der Plan ist, dass ich nun in neue Units oder aber wenn ich eine Bestandsunit bearbeite, diesen Part weg lasse bzw. raus nehme und dann dort gezielt gegen Warnungen programmieren kann.

Das Ganze funktioniert wie geplant nur an einer Stelle habe ich ein Problem: Code von Drittanbietern/Komponentenanbietern wird bei Projekterzeugung ebenfalls kompiliert und erzeugt Warnungen (z.B. von TMS, Devart, AsyncPro, Jedi). Ich würde gerne diese Sourcen im originalen Zustand belassen und dort keine Compiler-Direktiven unterbringen.

Sieht jemand eine Möglichkeit, wie ich diese Warnungen trotzdem aus dem Projekt bekomme, wenn sie vom Drittanbieter stammen ohne ganze Warnungstypen abzuschalten?

[himitsu]

Zitat:

und in die letzte Zeile {$WARNINGS ON} {$HINTS ON}.

Nicht nötig, denn diese Direktiven gelten eh nur lokal, also von da wo es deklariert wird, bis maximal zum Unitende.
(außer in der DPR, vor der Usesklausel, bzw. in den Projektoptionen)

Du kannst die Fremd-Codes in einen eigenen Projekt compilieren, wo das in den Projektoptionen deaktiviert wird. (oder lass' es einfach an)

Und in deinen Projekten/Delphi gibst du nur den Unit-Suchpfad zu den kompilierten DCUs and, womit sie nicht neu kompiliert werden und somit auch keine Warnungen erzeugen.
Werden die PAS z.B. zum Debuggen oder reingucken beim Programmieren benötigt, dann kommen die in den anderen Suchpfad.
Optionen... > Bibliothekspfad und Suchpfad (ich verqesse nur immer was wofür ist, da die intern in der Registry auch noch andersrum bezeichnet sind )


[edit]
Ups, vergessen zu schreiben.

Zitat:

Generell würde ich empfehlen, auch in Legacy Code die Meldungen zu bereinigen.

Da stimme ich zu.
Aber zumindestens sollte man dennoch wenigstens einmal alles durchschauen und vorallem die "wichtigen/schlimmen" Probleme beheben, bevor man das einfach so ausblendet.

[Stevie]

Generell würde ich empfehlen, auch in Legacy Code die Meldungen zu bereinigen. Bisschen Fleißarbeit aber vieles davon lässt sich ja relativ einfach lösen.

Für Drittanbieter Code empfehle ich auch immer wieder, den nicht jedesmal wieder aufs Neue in die Anwendung mitzukompilieren, sondern vorkompilierte DCUs zu nutzen.

Das sorgt dafür, dass man nur seine eigenen Meldungen bekommt und beschleunigt auch noch nebenbei den Kompiliervorgang (bzw Erzeugen).
Und ja, das geht auch wenn man seinen Drittanbieter Code mit in die Versionsverwaltung packt.

Zitat von himitsu:

Und in deinen Projekten/Delphi gibst du nur den Unit-Suchpfad zu den kompilierten DCUs and, womit sie nicht neu kompiliert werden und somit auch keine Warnungen erzeugen.
Werden die PAS z.B. zum Debuggen oder reingucken beim Programmieren benötigt, dann kommen die in den anderen Suchpfad.
Optionen... > Bibliothekspfad und Suchpfad (ich verqesse nur immer was wofür ist, da die intern in der Registry auch noch andersrum bezeichnet sind )

Ein Grund, warum ich Delphi in englisch benutze. Das nennt sich dort Browsing Path (die Verzeichnisse, wo die IDE nach dem Source nachschaut, um ihn im Editor anzuzeigen).
Die anderen beiden heißen Library path (Bibliothekspfad, globale Einstellung der IDE) und Search path (Suchpfad, lokale Einstellung im Projekt), wo man pas oder dcu Dateien liegen hat. Und hier ist meine Meinung, dass in den Library path keine Verzeichnisse mit Sourcen gehören.

[Bernhard Geyer]

Bis auf die Plattform-Warnungen (diese kann man ignorieren wenn man eh nicht vorhat in absehbare Zeit für MacOS/Android/iOS mit dem gleichen Quellcode zu programmieren) sollte man den standardwert von Delphi verwenden. Auch Warnungen können in sonderfällen aus der Sicht des Kunden fehler darstellen (z.B. Sonderzeichen werden wegen Wandlung Ansi/Unicodestring kaputt gemacht).

[Bernhard Geyer]

Zitat von Stevie:

Für Drittanbieter Code empfehle ich auch immer wieder, den nicht jedesmal wieder aufs Neue in die Anwendung mitzukompilieren, sondern vorkompilierte DCUs zu nutzen.

Das sorgt dafür, dass man nur seine eigenen Meldungen bekommt und beschleunigt auch noch nebenbei den Kompiliervorgang (bzw Erzeugen).
Und ja, das geht auch wenn man seinen Drittanbieter Code mit in die Versionsverwaltung packt.

Zeitfaktor würde ja nur den kompletten Rebuild betreffen.
und Warnungen/Hints würde ich auch gerne aus dem Code der Drittanbieter raus haben.
Einfach bei denen imemr wieder auf diesen (m.E.) Mangel hinweisen. Irgendwann setzt sich doch jemand hin und fixt das.

[Stevie]

Zitat von Bernhard Geyer:

Zeitfaktor würde ja nur den kompletten Rebuild betreffen.

Und das passiert mindestens einmal bei jedem Projekt, was man mal erstellt oder wenn man mal nen clean seines Working Repositories macht, nen Branch wechselt oder weiß der Geier (kein Wortspiel beabsichtigt).

[Dejan Vu]

Eine geringe Anzahl von Warnungen im Code von Drittanbietern ist auch ein Qualitätsmerkmal, das nur mal so am Rande.

Mir kommt aber auch nicht in den Sinn, deren Zeugs ständig mitzukompilieren. Nur wenn ich auf Wanzensuche bin, kommt das mal vor. Aber meinen Code mache ich auch ohne die Quellen der Drittanbieter sauber.

[Ralle1]

Danke für euer Feedback. Ich habe die Bibliothekspfade für die betroffenen Drittanbieter auf um *.pas Dateien befreite Kopien umgeswitcht. So geht es.
Komponenten und Drittanbieter ist immer wieder ein Kampf...

An alle die vor dem Abschalten der Warnungen warnen: nur so kann ich wieder sinnvoll auf Warnungen eingehen. Wenn es unzählige sind, ist es utopisch zu glauben, ich könnte sie alle aus der Welt schaffen.

[Stevie]

Zitat von Ralle1:

An alle die vor dem Abschalten der Warnungen warnen: nur so kann ich wieder sinnvoll auf Warnungen eingehen. Wenn es unzählige sind, ist es utopisch zu glauben, ich könnte sie alle aus der Welt schaffen.

Ich kann dir aus eigener Erfahrung (Source mit ehemals tausendenden Warnings/Hints) sagen, dass es nicht so ist. Man muss sich nur mal dran setzen. Klar, wird man die nicht mal ebend auf null bringen aber ich versprech dir, du wirst den einen oder anderen potenziellen oder gar tatsächlichen Bug damit beheben. Source will gepflegt werden, und das gehört dazu (auch wenn man in ner heilen Welt lieber gleich Source produziert, der keine hat)

[Bernhard Geyer]

Zitat von Stevie:

Ich kann dir aus eigener Erfahrung (Source mit ehemals tausendenden Warnings/Hints) sagen, dass es nicht so ist. Man muss sich nur mal dran setzen. Klar, wird man die nicht mal ebend auf null bringen aber ich versprech dir, du wirst den einen oder anderen potenziellen oder gar tatsächlichen Bug damit beheben. Source will gepflegt werden, und das gehört dazu (auch wenn man in ner heilen Welt lieber gleich Source produziert, der keine hat)

Vor allem bei so vielen Einträgen gehen auch neu Produzierte Warnungen unter.
Denn ob es 100 oder 105 Meldungen sind interessiert dann auch keinen mehr.
Als Entziel sollte sein das auch Warnungen ein Buildprozess zum Abbruch bringen.