Kritik

>... anbei eine kritische Diskussion von MISRA C.
>http://www.schellong.de/htm/misra.htm

>Ich denke die Grundidee ist gut, die Umsetzung
>aber weit über das Ziel hinausgeschossen!

Mal davon ab, dass einige Punkte mit MISRA2012 obsolet wurde, sind
einige Punkte schlicht (absichtlich?) falsch dargestellt.
Andere Punkte sind definitiv falsch.
Besonders zeigen einige Beispiele des Authors, die er _gegen_ MISRA listet
gerade auf, dass die Regel durchaus Sinn macht.
Gerade seine Komma-Kritik wird durch die Beispiele konterkariert, zumal
der Kontrollausdruck der for-Schleife damit schnell völlig unleserlich ist.
Hier ist es sehr viel sinnvoller auf eine gescheite Quelltextformatierung
zu setzen, indem man z.B. vor die Schleife mit Setup eine Leerzeile
oder einen Kommentar (Zeilenkommentar, hier stimme ich ihm klar zu) setzt.

Ein schönes Beispiel ist auch 6.3, wo er allen Ernstes völlig willkürliche
Typennamen für feste Int-Breiten vorschlägt, anstatt (wie auch MISRA es nicht macht)
stdint.h zu nehmen, die ja gerade das angesprochene Problem angehen.

Was implizite Typ-Konvertierungen angeht, so können moderne Compiler hier
durchaus mehr leisten, wenn man z.B. Konstanten sehr wohl als unsigned markiert.

Andere Punkte dagegen sind durchaus nachvollziehbar, wenn z.B. continue oder break
gefordert werden. Bei default dagegen schlägt der Author in eine ähnliche
Kerbe wie MISRA, ignoriert aber, dass es bei enum-switches durchaus sinnvoller
ist, default komplett wegzulassen, um dem _Compiler_ die automatische Prüfung
zu ermöglichen (was zumindest der gcc leisten kann).

Fazit: Lustiges Gemisch von berechtigter Kritik, Rant aus Bequemlichkeit
und schlechtem Programmierstil.

Das Problem mit MISRA habe ich insofern, als dass ich (laut Kundenfeedback)
ein sehr guter Programmierer bin, der eben auch von sich aus leserlichen
Code schreibt.
Ich würde durch MISRA definitiv massiv ausgebremst und der Code würde
unleserlicher mit, als nach meinen eigenen Regeln.
MISRA ist die Anwort von Managern auf die Frage, wie programmier-unerfahrene
Ingenieure fehlerarmen C-Code schreiben können.
Das Dilemma: es geht nicht!
Leider begreifen die Verantwortlichen das einfach nicht, oder nutzen
den Microsoft-Effekt aus: wenn der PC muckt unter Windows, kann man die Schuld
auf Microsoft abladen und man selbst ist fein raus;
wenn man dagegen Linux nutzt, ist man selber Schuld, wenn es mal Probleme gibt.
Genau _so_ "verkauft" sich MISRA.
Letztlich können nur gute _embedded_ Programmierer guten Code schreiben.
Die brauchen dann aber auch kein MISRA, sondern gescheite Style Guides.
Damit kann man auch einige extrem nützliche Extensions moderner Compiler
wie GCC erlauben, die gerade auch zur Qualtität des Codes massiv beitragen
können (Stichworte "gcc plan9-extensions").
MISRA stammt immerhin aus einer Zeit, als die meisten embedded Compiler
noch K&R-C implementierten und moderne Programmiertechniken (also der 70er Jahre!)
den Auto-Ingenieuren völlig unbekannt waren.
Das gilt leider auch für die Leute, die MISRA erst definiert hatten.
Inwieweit das mit MISRA-2012 anders ist, kann man leider aufgrund
der Paywall nicht so einfach feststellen.


>Toll finde ich ja auch seinen Kommentar von zum Verbot von rekursiven Funktionen,
>gerade im Automotive Embedded Bereich, wo wir ja auch soooo große Stacks haben.

Ok, Rekursion habe ich bislang nun wirklich nicht vermisst (und das, wo ich bislang
um MISRA drum rum kam.

>Ich glaube, der hat nie in einem Automotive Embedded Bereich geschafft, wenn ich
>seine Kommentare so lese.

Ich auch ned, wundere mich aber dauernd über die - trotz MISRA - häufingen
Liegenbleiber und Rückrufe wegen Softwarefehlern in Steuergeräten.
Und das ausgerechnet in den "Premium" Mühlen.
Wie gesagt: erfahrene SW-Entwickler brauchen MISRA bestenfalls anfangs als Liste
möglicher Pitfalls (dafür ist es tatsächlich ok, wenn auch (MISRA-2004) massiv unvollständig).
Und schlechte Progger werden mit MISRA nicht wirklich guten Code schreiben.

>Klar ist aber auch, daß manche MISRAC Verbote an die Substanz gehen können, gerade
>auch was die cast-erei angeht.
>Wenn der MISRAC Checker dann erst bei Konstrukten wie
>    ((uint32)~((uint32)x << y) | ((uint32)a << z)))
>zufrieden zu stellen ist, da geht dann die Tilde voll im Cast unter.

Zumal, wenn dann (y|z)>31 sein kann.

Antwort auf die Kritik

• Welche Punkte sind schlicht falsch dargestellt?
• Welche Punkte sind definitiv falsch?
• Welche Kritikpunkte zeigen, daß die Regel durchaus Sinn macht?
• for (s=384,i=0;  i<64;  ++i,s-=2)
  Wieso soll das völlig unleserlich sein?
• Die Typennamen für feste Int-Breiten sind beispielhaft.
  Der Header stdint.h ist in Entwicklungssystemen mitunter
  nicht vorhanden! Beispielsweise in Softune von Fujitsu.
  Die krasse Kritik zeugt folglich von mangelnder Kenntnis.
• Der Kritiker verengt die Sicht auf bestimmte Compiler und argumentiert damit.
  Das ist in diesem Kontext unangebracht und zündet nicht.
• Die Behauptung, Compiler würden bei 46u (oft) optimieren, bei 46 jedoch nicht,
  ist nicht haltbar.
  Beispielsweise gibt es keinen Unterschied bei u/27 und u/27u.
  Sinnvoll ist 1u<<22.
  Compiler erkennen eine Int-Konstante mit nicht negativem Wert
  und verhalten sich (oft) so, als hätte die Konstante den Typ unsigned.
• Der Kritiker hat schlechten Programmierstil erkannt, ohne eine C-Quelle
  gesehen zu haben. Das ist so nicht ernst zu nehmen und wertlos.
• Der Autor spricht nirgendwo von Automotive Embedded Bereich.
  Warum sollte er auch seine Aussagen so spezialisieren?
  Außerdem ist der Stackbedarf eines rekursiven Funktionsaufrufs vorhersagbar.
  Dieser kann bei nur 8 Byte einzeln liegen, bei einem Stack von 2 KB oder auch 16 KB.
  Rekursion ist praktisch unverzichtbar, wenn Verschachtelungen aufgelöst werden müssen.
  Den Kritikern fehlt es an Erfahrung.

Diese Kritik bekam im ct-Forum sofort (blinde) Anhänger. Das ist oft so, wenn jemand relativ viel Text schreibt und eine Kompetenz vermittelt, die oberhalb eines bestimmten Grades liegt.
Ähnlich ist es mit glückseligen Buchrezensionen von Unerfahrenen, denen sich automatisch viele andere Unerfahrene anschließen. Bis dann ein Hochkompetenter kommt, der das Buch zu Recht als unbrauchbar in Grund und Boden stampft und ebenfalls sofort dankbare Anhänger gewinnt.