Handling von Fehlern, Warnungen und Hints

[Dezipaitor]

Zitat von HeikoAdams:

Zitat von Dezipaitor:

"Rückgabewert der Funktion AddSecurityPackageW könnte undefiniert sein" - Das ist hier falsch.
Hier ein "result := " einzufügen wäre wahnsinnig, da man ein paar tausend Funktionen anpassen müsste.

Das bedeutet im Umkehrschluss, das Du vom Compiler erwartest, das er bei Funktionen nicht nur nach "Result :=" oder "Funktionsname :=" suchen soll, sondern auch noch eventuell vorhandenen ASM-Code parsen soll, ob eventuell dort das entsprechende Register bestückt wird?

Nein, natürlich nicht. Aber wenn es sowas wie {$WARN UNDEFINED_RESULT OFF} und {$WARN UNDEFINED_RESULT DEFAULT} gegeben hätte, dann wären nun über 3000 Funktionen, die semantisch korrekt einen Rückgabewert liefern, ohne diese Warnungen. Dadurch würden Warnungen aufgedeckt, die auch stimmen.

Zitat:

Sorry, aber wer zu faul ist, "Result :=" oder "Funktionsname :=" in seine Funktion zu schreiben, der hat nichts anderes als die entsprechende Warnung verdient.

Ich glaube, du wärst auch zu faul, dies in über 3000 Funktionen einzubauen. Zudem wäre das ein beträchtlicher Anstieg von Code in der Binärdatei. Außerdem ist jeder Aufruf mit Zeitverlust verbunden, da, wenn von Delphi nicht herausgerechnet, ja auch Code ausgeführt wird. Und bei einer Library weiß man nie wie oft die Funktionen aufgerufen werden. Würde ich nur wegen den Warnungen überall, ein Result einfügen, dann würde ich sicherlich eine Menge Mails deshalb bekomme, warum der Code so groß geworden ist (bei vielen Funktionsaufrufen).

Zitat:

Ebenso gefährlich finde ich, das es überhaupt die Möglichkeit gibt, Warnungen für ein gesamtes Projekt zu deaktivieren. Nur weil die Warnungen im Moment unbegründet sind, darf man als verantwortungsvoller Entwickler nicht davon ausgehen, dass das auch zukünftig der Fall ist!

Es ist viel gefährlicher, wenn man von ungültigen Warnungen bomadiert wird und bei einer riesigen Liste die echten Warnungen nicht mehr sieht. Zudem dauert die Erstellung von Projekten mit vielen Warnungen sehr lange. Es mag für den Anwendungsentwickler nicht von belang sein, aber für große Projekte und Libs ist das nicht förderlich.

Zitat:

Zitat von Dezipaitor:

Globale Variablen werden schon immer mit 0 initialisiert.
Das ist ein dokumentiertes Verhalten und wird sicher nicht in Zukunft geändert.

Dazu sage ich nur: Verlass Dich auf andere und Du bist verlassen.
Wer sagt Dir, das es nicht zukünftig einen (ge)wichtigen Grund für CodeGear gibt, das beschriebene Verhalten doch zu verändern?

Garantie wird es keine geben. Da es jedoch dokumentiert ist, kann man sich darauf verlassen, dass die Kompatibilität beibehalten und bei einer Änderung frühzeitig bescheid gegeben wird. Wäre das nicht so, würden eine Menge Delphianwendungen von heute auf morgen nicht mehr funktionieren. Das kann ich garantieren. Schließlich wird auch nicht plötzlich die Prozedur Inc geändert, so dass sie dekrementiert.

Zitat:

Mein Informatik-Lehrer hat uns förmlich eingeprügelt, anstellen von
if a <= b then nur
if (a <= b) then zu schreiben, da man nie sicher sein kann, das sich das Verhalten des Compilers in diesem Punkt nicht doch irgendwann ändert.
Sein Credo war damals: Im Leben ist nur eins sicher: Man stirb früher oder später.

Klammern zu schreiben ist ja ok. Besonders wenn es größere Bedinungen gibt, ist das ein muss. Aber es ist normal, dass man in der Lehre etwas härter darauf trainiert wird, niemandem und nichts zu vertrauen. Aber wenn man das auf die Wirtschaft übertragen würde, würde es wohl einen Stillstand geben.

Zitat von alzaimar:

*schnipps* *meld*
Ah... Wieso nicht einfach bei Hack-Units die Warnungen ausschalten? Solche Units basieren eh auf dem Compiler und sind weder Plattform- noch Compilerunabhängig, weil auf bestimmte Registerkonventionen, Stackaufbau usw. gebaut wird.
Man umgeht in so einem Hack sowieso (aus Performancegründen oder weil es anders einfach nicht geht) das Bestreben einer modernen Programmiersprache, schwere Fehler zu vermeiden und setzt sich bewusst der Gefahr aus, das System zu zerballern.

Man kann es nicht für diese Units allein ausschalten, da WARNINGS OFF global, also für alle Units gilt. Wenn der compiler einmal an diese Direktive angekommen ist, dann gibt es danach für eigene Units keine Warnungen mehr.