IDE plötzlich alles voller Fehler

[Neutral General]

Die "Fehlermarkierung" hat seit ich mit Delphi angefangen hab (vor ungefähr 15 Jahren) noch nie funktioniert und hat schon immer eine lange Liste von erfundenen "Fehlern" angezeigt.
Bis darauf die IDE (noch) langsamer zu machen hat das Feature keinen Nutzen (weswegen das das Erste ist was ich nach einer Installation ausschalte).

[Guido Eisenbeis]

Hallo Michael.

Zitat von Neutral General:

Die "Fehlermarkierung" hat seit ich mit Delphi angefangen hab (vor ungefähr 15 Jahren) noch nie funktioniert und hat schon immer eine lange Liste von erfundenen "Fehlern" angezeigt.

Dann habe ich mir doch nicht eingebildet, dass ich das schonmal hatte. (Aber diesmal werde ich mir in meine Tipps schreiben, was es verursacht!)

Eigentlich finde ich die Fehlermarkierungen ganz gut. Aber nur mal für den Fall, wo findet sich denn er Ausschalter?

[Neutral General]

Tools -> Optionen

Benutzeroberfläche -> Editoroptionen -> Code Insight

[ ] Fehlermarkierung

[Uwe Raabe]

Zitat von Neutral General:

Bis darauf die IDE (noch) langsamer zu machen hat das Feature keinen Nutzen (weswegen das das Erste ist was ich nach einer Installation ausschalte).

Bedauerlich! Seit ich meine Units sauber strukturiere und zyklische Abhängigkeiten gnadenlos eliminiere, habe ich solche Fehler eigentlich gar nicht mehr. Ob die IDE dabei nun gefühlt schneller oder langsamer ist, sei mal dahingestellt. Das Coden geht damit auf jeden Fall deutlich schneller.

Ich ärgere mich immer wieder bei Fremd- bzw. Kunden-Projekten über die verlorene Zeit, wenn das eben nicht der Fall ist (in der Regel leider fast immer). Ich habe aber auch noch keinen Ansatz gefunden, diese Zeit irgendwie zu beziffern. Das wären vermutlich schlagende Argumente für ein Refactoring.

[Neutral General]

Eine deutliche Verlangsamung der IDE aufgrund dieses einen Features kann ich jetzt auch nicht nachweisen. Aber es ist eine Funktion die ausgeführt werden muss.
Und was ausgeführt wird verbraucht CPU Power.

Der Code auf der Arbeit braucht definitiv ein Refactoring - und wir sind auch dabei, aber es ist halt ein langer Prozess. Ich programmiere mittlerweile nur noch selten zu Hause an Code den ich komplett selbst geschrieben habe (ich versuche generell schon auf sauberen Code und saubere Abhängigkeiten zu achten, aber mit ner alten Codebase und vielen anderen "Köchen" ist das auf der Arbeit schwer).
Von daher kann es durchaus sein, dass die Fehlermarkierung unter den richtigen Umständen tatsächlich funktioniert.

Trotzdem frage ich mich warum die Fehlermarkierung da zumindest empfindlicher/fehleranfälliger ist, wenn Embarcadero doch den Code hat um fehlerfrei festzustellen ob die Syntax des Codes korrekt ist oder nicht. Da benutzt die Fehlermarkierung gefühlt einfach einen schlechteren Parser als der Compiler. Und das versteh ich irgendwie nicht so wirklich

Unterm Strich hab ichs ausgeschaltet weil ich über die Jahre mehr Falschmeldungen als wahre Fehler angezeigt bekommen habe und ich das Feature selbst wenn es funktionieren würde nicht besonders hilfreich/notwendig finde.

[Uwe Raabe]

Zitat von Neutral General:

Da benutzt die Fehlermarkierung gefühlt einfach einen schlechteren Parser als der Compiler.

Ja, das ist in der Tat so - und soll in den nächsten Versionen geändert werden. Ideal wäre nur ein Parser, der alle Teile der IDE bedient.

[TurboMagic]

Ja, es soll ein besserer und extern angebundener Parser in Zukunft benutzt werden.
Der läuft dann ja als eigener Prozess, was auch der IDE Geschwindigkeit zuträglich
sein sollte.

Wobei ich jetzt bisher nicht feststellen konnte, dass der bisherige Parser die
IDE merklich verlangsammt.

Nut: die Sache mit dem Pfad der bestimmte Zeichen kombinationen enthält sollte
bitte in QP als Bug gemeldet werden! Evtl. auch mal testen ob das generell evtl.
mit Pfaden die Leerzeichen enthalten zu tun hat?

[jaenicke]

Zitat von Uwe Raabe:

Bedauerlich! Seit ich meine Units sauber strukturiere und zyklische Abhängigkeiten gnadenlos eliminiere, habe ich solche Fehler eigentlich gar nicht mehr.

Ja, das haben wir auch gemerkt. In unseren aktuellen Quelltexten mit sauberer Struktur und sauberen Dateistrukturen haben wir auch keine nennenswerten Probleme mehr mit Code Insight.

Ich hoffe, dass der neue Parser dann nächstes Jahr kommt und auch unsere älteren Quelltexte dann damit besser nutzbar sind.
Trotzdem ist die Fehlerquote von Code Insight auch ein Gradmesser für die Sauberkeit des Codes, wenn auch nicht zu 100% genau...

Ich nutze Code Insight aber auch in XE6, wo noch deutlich mehr falsche Fehlermarkierungen angezeigt wurden, weil man nach einer Weile meist recht gut ohne groß nachzudenken weiß welche Fehler falsch sind und welche wirklich welche sind.

[Redeemer]

Na ja, das Ding heißt zwar ErrorInsight, wird aber aus gutem Grund ErrorInside genannt.

In D2010 kriegt man das ganz einfach dazu, die Grätsche zu machen: Sobald du in deinem Projekt einen Record-Helper hast, ist der gesamte Quelltext rot. Keine Ahnung, bis zu welcher Version das so ist. Ebenfalls hasst es Generics und insbesondere deren Erben.

Die Deinstallation von Delphi 10.2 hat allerdings auch ErrorInside von Delphi 2010 deinstalliert. Dann war erstmal erzwungenermaßen Ruhe.

[jaenicke]

Zitat von Redeemer:

Ebenfalls hasst es Generics und insbesondere deren Erben.

Das ist schon lange vorbei. Selbst bei XE war das normalerweise kein Problem mehr. Und mit 10.2 geht es auch bei den meisten älteren Quelltexten von uns. Bei Kreuzreferenzen geht es halt in die Knie manchmal wie Uwe schon schrieb. Aber das ist ja ok, macht man eh nicht.