Verbannung von -fpermissive

« | 26 Jul 2020 | »

O-M-G !
Es tut mir ja echt leid, wenn ich jemanden damit beleidige, aber:

Wenn sich ein Projekt nur noch mit -fpermissive bauen lässt, sollte man es löschen und wieder von vorne beginnen.

Warum werden Probleme immer unter den Teppich gekehrt und wöchentlich ein neuer Teppich gekauft, anstatt den Müll gleich am Anfang aufzusaugen??

---

Wenn Compiler Warnungen ausgeben, dann tun sie das nicht aus Jux und Tollerei. Natürlich kann man schon mal ein Auge zudrücken, wenn ein signed und ein unsigned Integer verglichen wird, wenn man selbst weiß, es werden immer nur positive Zahlen verglichen. (Und auch hier würde ein expliziter Cast alle Warnungen verschwinden lassen.)

Aber wenn der Compiler einen Fehler ausgibt und klar aussagt:

Was du da geschrieben hast ergibt keinen Sinn oder ist syntaktisch falsch.

dann ist es einfach nur dumm auch das zu ignorieren.

“-fpermissive”

Der GCC Parameter -fpermissive wandelt einige “Fehlerdiagnosen” in ignorierbare Warnungen um.
Und leider nutzen faule Entwickler dieses “Feature” um defekten Code zum Kompilieren zu bekommen, der eigentlich nie so übernommen werden dürfte.

Dieses Problem ist wie so vieles in der IT “historisch”. Zwar gibt es am Anfang meist einen “Standard”, doch kein Compiler setzt diesen vollständig um. Frühere Versionen übersetzen somit Code-Konstrukte in “irgendetwas” und wenn dieses “etwas” keine sichtbaren Abstürze produziert, wird angenommen, es sei richtig.

Kommt nun aber eine neue Compilerversion heraus, erkennt diese im alten Code Fehler und meldet diese während die Übersetzung abgebrochen wird.

Genau an der Stelle müsste jetzt der Entwickler ein paar Stunden Zeit investieren und sein defektes Fabrikat überarbeiten und die Welt wäre wieder in Ordnung.

Aber nein, man sucht lieber ein paar Stunden in den Dokus nach Compiler-Flags um die Fehlermeldung zu unterdrücken und zu verheimlichen.

Das Kosten-Problem

In allen Unternehmen, in denen ich bisher gearbeitet habe gilt das Prinzip:

Fehlerkorrekturen sind unnötig, weil wir nur perfekte fehlerfreie Produkte im Sortiment haben.
Wir bezahlen nichts, was nicht bestellt wurde.

Und ganz furchtbar wird es dann, wenn es beim “SCRUM-Review” heißt:

Fehlerkorrektur war nicht Teil der Userstory.

Tja, und so investieren alle immer nur Zeit in Workarounds und verschlimmern mit jeder Anpassung das Problem, weil jede weitere nicht-standard-konforme Zeile weiteres Fehlerverhalten und Verkomplizierung bedeutet.

Fazit

Es macht keinen Sinn, dass ich mich wieder darüber aufrege, dass ich berufsbedingt mit Code arbeiten muss, der nie hätte so geschrieben werden dürfen.

Die Lösungen heißen natürlich “Bildung” und “Qualitätsmanagement”, doch noch nie habe ich einen Qualitäts-Planer kennen lernen dürfen, der Softwareentwicklung verinnerlicht hätte.
Dort geht es dann leider immer nur um Kosmetik nach Außen und offensichtliche Defekte, wenn bereits ein ganzer Wirtschaftszweig zusammengebrochen ist.

Dabei müsste man schon in der Architekturplanung anfangen, auf “korrektes Arbeiten” zu achten, aber hier fehlt es - und ich bedauere dieses Urteil - leider oft an Intelligenz.

However, ich freue mich daher im GATE Projekt zumindest teilweise beweisen zu können, dass der Compiler unser Freund ist. Fast jede Warnung hat mich zu einer fehlerhaften oder unvollständigen Implementierung geführt, die ich somit ausbessern konnte.
Und so sind die wenigen verbliebenen Warnungen auf Fremdbibliotheken zurückzuführen.

Und ich kann nicht oft genug betonen, dass die Zeit zum Bereinigen von Sourcecode einen Bruchteil dessen verfrisst, was man dann Herumsuchen kann, wenn eine ignorierte Warnung- oder Fehlermeldung mal im Produktivsystem “schlagend” wird.