Auswahl von Leitlinien: MISRA 1998 oder MISRA 2004 oder MISRA 2012?

Question

Ich habe mich immer gewundert, wie wählt ein Projekt/Team/Unternehmen aus oder qualifiziert sich für die Auswahl einer spezifischen Richtlinie wie MISRA 1998/2004/2012? Wie sollte man wissen und entscheiden, welche Richtlinie für die Qualifizierung eines Projekts ausreichend ist (Kosten pro Zeit gegen Qualität)?

(Ich weiß, dass seine Frage ein bisschen stumpf ist, aber alle Antworten zu erkennen ist)

Answer 1

Dies ist oft eine Anforderung aus dem Anwendungsgebiet. Sie haben Sicherheitsstandards, die vorgeben, dass eine sichere Teilmenge der Programmiersprache verwendet wird. Diese Anforderung kann von den "SIL" -Standards wie der Industrie-IEC 61508, der Automobil-IEC 26262, der Raumfahrt-DO-178 und so weiter kommen. In solchen unternehmenskritischen Systemen haben Sie möglicherweise keine andere Wahl, als MISRA-C zu verwenden.

Aber MISRA-C wird auch Industriestandard für alle eingebetteten Systeme, unabhängig von ihrer Natur. Der Grund dafür liegt auf der Hand: Niemand, egal welchen Anwendungsbereichs, mag schlechte, minderwertige Software voller Bugs.

Einführung von MISRA-C, zusammen mit Kodierungsrichtlinien, Stilregeln, statischen Analysen, Versionskontrolle ... alles wird die Qualität des Endprodukts erheblich verbessern. Und es wird die Programmierer zwingen, sich über C zu informieren und insgesamt professioneller zu werden.

MISRA-C ist nicht unbedingt das am besten geeignete Regelwerk für jedes Unternehmen. Es ist meistens auf eingebettete Systeme anwendbar. Für andere Arten von Anwendungen könnte etwas wie CERT-C relevanter sein. Es ist bequem, einen dieser bekannten Standards zu verwenden, denn dann können Sie Tests mit statischen Analysatoren automatisieren.

Der Schlüssel hier ist, dass jede semiprofessionelle Firma, die Software produziert, eine Art von Codierungsregeln benötigt, die sich auf verbieten schlechte Praxis. Einige Unternehmen neigen dazu, sich viel zu sehr auf die meist unwichtigen Stildetails zu konzentrieren, wie zum Beispiel, wo sie sich auf Dinge konzentrieren sollten, die wirklich die Softwarequalität verbessern, wie "wir sollten vermeiden, funktionsähnliche Makros zu schreiben".

Die Codierungsregeln sollten in Entwicklungsroutinen integriert werden. Es macht wenig Sinn, MISRA-C für ein einzelnes Projekt zu implementieren. Es gibt eine Menge Arbeit, um es in Gang zu bringen.

Es ist sehr wichtig, dass Sie mindestens einen, vorzugsweise mehrere C-Veteranen mit langjähriger Erfahrung haben, die Sie für die Kodierungsregeln verantwortlich machen. Sie müssen jedes schmutzige Detail des MISRA-Dokuments lesen und entscheiden, welche Regeln für die Implementierung des Unternehmens sinnvoll sind. Einige der Regeln sind bei weitem nicht trivial zu verstehen. Nicht alle sind in jeder Situation sinnvoll. Wenn dein Entwickler-Team nur aus Anfängern oder erfahrenen Programmierern besteht und du entscheidest, MISRA genau zu folgen, wird es schlecht enden. Sie benötigen mindestens einen erfahrenen Programmierer, der über ausreichende Kenntnisse verfügt, um zu entscheiden, welche Regeln zu befolgen sind und von welchen Regeln abgewichen werden soll.

Für welche Version von MISRA-C zu wählen, verwenden Sie immer die neueste: 2012. Es wurde ziemlich aufgeräumt und einige seltsame Regeln wurden entfernt. Es unterstützt auch C99, im Gegensatz zu den älteren.

Answer 2

Genau wie bei Ihrer Compiler-Suite oder Entwicklungsumgebung und/oder Ihren statischen Analysewerkzeugen sollte die geeignete Version am Anfang eines Projekts festgelegt werden, da es später schwierig sein kann, sie zu ändern!

Wenn Sie ein Projekt von Grund auf neu beginnen, dann würde ich empfehlen, dass MISRA C: 2012 angenommen wird - vielleicht auch die Führung des neuen (April 2016) die Annahme MISRA Compliance

Die neue Compliance-Beratung bietet auch Beratung Wie behandelt man Adopted Code (dh bereits existierenden oder importierten Code).

Vorhandene Projekte, die zu früheren Versionen entwickelt wurden, sollten diese frühere Version weiterhin verwenden ... es sei denn, es gibt einen guten Geschäftsfall für Änderungen. Änderungen führen zu Nachbesserungen!

Answer 3

Der Code muss so geschrieben sein, dass er bestimmte gewünschte Eigenschaften (Qualitätskriterien) aufweist. Einige Qualitätskriterien sind praktisch immer erwünscht, wie Korrektheit, Lesbarkeit, Wartbarkeit (auch hier sind Ausnahmen, zB wenn Sie für den obfuscated c contest oder den undhanded c contest programmieren). Andere Qualitätskriterien sind nur für bestimmte Projekte oder Organisationen relevant, z. B. Übertragbarkeit auf 16-Bit-Maschinen.

Eine gut formulierte Codierungsregel unterstützt in der Regel ein oder mehrere Qualitätskriterien. Es kann jedoch zu Konflikten mit anderen kommen. Es gibt eine große Anzahl etablierter Codierungsregeln, die die typischerweise gewünschten Qualitätskriterien unterstützen, jedoch ohne signifikante negative Auswirkungen auf andere. Viele davon sind schon vor langer Zeit bekannt (Kernighan und Plauger: Elemente des Programmierstils, 1974, und, ja, ich habe eine Kopie davon :-). Manchmal werden zusätzliche gute Regeln identifiziert.

Wenn nicht in sehr seltenen Fällen (wie vorsätzliche Verschleierung) Code sollte folgen diese "bewährten Regeln", unabhängig davon, ob sie Teil von MISRA-XXXX sind oder nicht. Und wenn eine neue gute Regel gefunden wird, vergewissern Sie sich, dass die Leute dem folgen. Sie können sogar entscheiden, diese neue gute Regel auf bereits vorhandenen Code anzuwenden, aber das ist wegen des damit verbundenen Risikos eher eine Managemententscheidung.

Es macht einfach keinen Sinn, einer guten Regel nicht zu folgen, nur weil sie nicht Teil von MISRA-XXXX ist. Ebenso macht es keinen Sinn, einer schlechten Regel zu folgen, nur weil sie Teil von MISRA-XXXX ist. (In MISRA-C-2004 heißt es, dass sie 16 Regeln aus MISRA-1998 entfernt haben, weil "sie keinen Sinn ergaben" - hoffentlich haben einige Entwickler sie bemerkt und nicht angewendet. Und, wie Lundin erwähnt, in MISRA-2012 wieder einige "seltsame Regeln" wurden entfernt.

Beachten Sie jedoch, dass für fast jede Regel ihre gedankenlose Anwendung in bestimmten Situationen sogar die Qualitätskriterien herabsetzen kann, die sie normalerweise unterstützt.

Zusätzlich zu diesen allgemein gültigen Regeln gibt es Regeln, die nur relevant sind, wenn bestimmte Qualitätskriterien für Ihren Code vorhanden sind. Erschwerend kommt hinzu, dass in den meisten Projekten für verschiedene Teile des Codes die verschiedenen Qualitätskriterien unterschiedlich relevant sind.

Für eine Interrupt-Service-Routine ist die Leistung wichtiger als für die meisten anderen Teile der Software. Daher Kompromisse mit. andere Qualitätskriterien werden gestellt.

Einige Softwareteile sind so konzipiert, dass sie zwischen verschiedenen Umgebungen tragbar sind, oft jedoch durch Einführung von Adaptern/Wrappern, die dann für eine bestimmte Umgebung spezifisch sind. Daher ist der Adapter selbst nicht dazu vorgesehen, tragbar zu sein.

Mit Ausnahme der oben genannten "bewährten Regeln" kann ein festgelegter Satz von Codierungsregeln folglich nicht für alle Teile einer typischen Software gut funktionieren. Bestimmen Sie daher für jeden Teil der Software zunächst, welche Qualitätskriterien für diesen Teil relevant sind. Wenden Sie dann diese Muster, Prinzipien und Regeln an, die diese spezifischen Qualitätskriterien wirklich angemessen unterstützen.

Aber was ist mit MISRA? Die MISRA-Regeln sollen Qualitätskriterien wie Korrektheit über Analysierbarkeit (z. B. Rekursionsverbot und dynamische Speicherverwaltung), Portabilität (z. B. Isolation von Assemblercode) unterstützen. Das heißt, bei Softwareteilen, bei denen diese spezifischen Qualitätskriterien nicht relevant sind, bringen die jeweiligen MISRA-Regeln keinen Nutzen. Leider hat MISRA keine Vorstellung von Softwarearchitektur, bei der verschiedene Teile unterschiedliche Qualitätskriterien haben.

Während sich viele Regeln gegenüber den MISRA-Releases verbessert haben, gibt es immer noch viele Regeln, die strenger als nötig sind (zB "no/* in // comments und vice versa" - warum?) Und Regeln, die zu vermeiden versuchen (unwahrscheinlich) Fehler auf eine Weise, die eher zu Problemen führt als zu deren Lösung (z. B. "keine Wiederverwendung eines Namens, nicht einmal in verschiedenen lokalen Bereichen"). Hier ist mein Tipp für Sie: Wenn Sie a) wirklich wollen, dass Ihr Regel-Checker alle Fehler findet und b) nichts dagegen hat, eine absurde Menge an Warnungen mit einem hohen falsch-positiven Verhältnis zu erhalten, dann tut diese eine Regel/Kontrolleur alles dafür Sie: "Warnung: Codezeile erkannt: < Codezeile>".

Schließlich wird MISRA unter der Annahme entwickelt, dass C (insbesondere seine Arithmetik) zu schwer zu verstehen sind. MISRA entwickelt seine eigene Arithmetik auf der Oberseite von C in der Überzeugung, dass Entwickler stattdessen die MISRA-Arithmetik lernen sollten und dann ohne C-Arithmetik davonkommen können. Offensichtlich war dies nicht erfolgreich, weil das MISRA-2004-Modell ("zugrunde liegender Typ") in MISRA-2012 durch einen anderen ("essentiellen Typ") ersetzt wurde. Wenn Ihr Team C also gut versteht und ein gutes statisches Analysewerkzeug (oder sogar mehrere) verwendet, das in der Lage ist, die problematischen Szenarien mit Cs Arithmetik zu identifizieren, ist der MISRA-Ansatz wahrscheinlich nicht für Sie geeignet.

TL; DR: Befolgen Sie die Standard-Best Practices, wenden Sie bewährte Regeln an. Identifizieren Sie spezifische Qualitätskriterien für die verschiedenen Teile Ihrer Architektur. Wenden Sie für jeden Teil Muster, Prinzipien und Regeln an, die für diesen Teil geeignet sind. Verstehen Sie Regeln, bevor Sie sie anwenden. Wende keine dummen Regeln an. Verwenden Sie eine gute statische Codeanalyse. Stellen Sie sicher, dass Ihr Team C.

versteht