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 :stupid:)


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

Zitat von himitsu (Beitrag 1275087)

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 :stupid:)

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:

Zitat von Stevie (Beitrag 1275092)

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:

Zitat von Bernhard Geyer (Beitrag 1275095)

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:

Zitat von Ralle1 (Beitrag 1275156)

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:

Zitat von Stevie (Beitrag 1275161)

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)

:thumb:
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.

[OlafSt]

Ich persönlich lasse keine von mir geschriebene Software aus dem Haus, das nicht 100% ohne Warnungen und Hints compiliert (Fremd-Libs mal ausgenommen, da wird noch massig geschlampt). Allerdings ist das "geh mal durch den Source und fixe das alles - es lohnt sich" auch nicht immer der Weisheit letzter Schluß.

Eines meiner übernommenen Alt-Projekte ist so ein Fall, da hagelt es Warnungen und Hints. Okay, keine 10k davon, aber 500-600 sind es schon. Ich habe in einer Unit angefangen, das zu beheben und dabei haarsträubendes zu Gesicht bekommen... Aber egal. Dummerweise funktionierte die Software in einzelnen Teilen bei einigen Kunden schlagartig nicht mehr :(

Hier wurden die klaren Unsauberkeiten übernommen, stillschweigend akzeptiert, was drumrum gebastelt und damit zu Features, die im Laufe der Jahre zu noch besseren Features erweitert wurden - ihr kennt das Prozedere.

Meine Aufräumarbeiten zerlegten damit einige "Features" und ich war nie glücklicher über ein funktionierendes SVN ;)

[Stevie]

Tja, nicht umsonst schreiben Leute Bücher darüber, wie man mit solchem Code umgeht ;)

[Ralle1]

Ich unterscheide zwischen Code, der einfach nur läuft und praktisch nie verändert wird und Code an dem regelmäßig gearbeitet wird. Ersteres soll keine Warnungen mehr bringen, weil die Zeit fehlt sie zu bearbeiten und weil "never touch the running....". An Code der ständig angefasst wird soll die Compilerdirektive beim nächsten Anfassen der Unit wieder raus genommen werden. Dann hat man eine überschaubare Menge an alten Warnungen, die man im Alltag mit ständig fehlender Zeit mal eben weg machen kann.

Weiter oben hieß es {$WARNINGS OFF} {$HINTS OFF} gilt immer für die ganze Unit. Kann man eine Warnungen für eine einzelne Methode oder Zeile unterdrücken? Es gibt ja immer wieder diese Stellen, wo man dann etwas macht weil es aus irgendeinem Grund so sein muss...

[Stevie]

Zitat:

Zitat von Ralle1 (Beitrag 1275201)

Weiter oben hieß es {$WARNINGS OFF} {$HINTS OFF} gilt immer für die ganze Unit. Kann man eine Warnungen für eine einzelne Methode oder Zeile unterdrücken? Es gibt ja immer wieder diese Stellen, wo man dann etwas macht weil es aus irgendeinem Grund so sein muss...

Klar, einfach wieder anschalten nach der Methode/Zeile :)

[Ralle1]

Ah das ist ja einfach :wink: :thumb:
Vielen Dank!!

[Dejan Vu]

Zitat:

Zitat von OlafSt (Beitrag 1275192)

Eines meiner übernommenen Alt-Projekte ist so ein Fall, da hagelt es Warnungen und Hints. Okay, keine 10k davon, aber 500-600 sind es schon. Ich habe in einer Unit angefangen, das zu beheben und dabei haarsträubendes zu Gesicht bekommen... Aber egal. Dummerweise funktionierte die Software in einzelnen Teilen bei einigen Kunden schlagartig nicht mehr :(

Hier wurden die klaren Unsauberkeiten übernommen, stillschweigend akzeptiert, was drumrum gebastelt und damit zu Features, die im Laufe der Jahre zu noch besseren Features erweitert wurden - ihr kennt das Prozedere.

Ein, zwei Beispiele / Anekdoten wären klasse.

Mir ist gerade sowas eingefallen:

Delphi-Quellcode:

Function RandomishFoolishness:Integer;
Var
  foo : Integer;

Begin
  Result := Foo;
End;

K.a. ob das auch ohne Foo funktioniert.

[Bernhard Geyer]

Zitat:

Zitat von OlafSt (Beitrag 1275192)

Eines meiner übernommenen Alt-Projekte ist so ein Fall, da hagelt es Warnungen und Hints. Okay, keine 10k davon, aber 500-600 sind es schon. Ich habe in einer Unit angefangen, das zu beheben und dabei haarsträubendes zu Gesicht bekommen... Aber egal. Dummerweise funktionierte die Software in einzelnen Teilen bei einigen Kunden schlagartig nicht mehr :(

Hier wurden die klaren Unsauberkeiten übernommen, stillschweigend akzeptiert, was drumrum gebastelt und damit zu Features, die im Laufe der Jahre zu noch besseren Features erweitert wurden - ihr kennt das Prozedere.

Dieser Fall i.m.E. ein 1a Fall von Lava Flow