Hallo,
es gibt ja zehn verschiedene MISRA Rules in C. Wie geht ihr damit um? Sollten am Ende des Projekts alle MISRA Rules eingehalten bzw. Violations beseitigt ein? Priorisiert ihr die 10 Regeln? Wie bzw. nach welcher Klassifizierung?
Gruß
AXL
Da es nicht nur „ein“ MISRA-C gibt, mal die Frage, welche „10“ Regeln Du denn meinst?
Hast Du ein Handbuch dazu da (kostet selbst legal nur eine Handvoll Dollar)?
Hast Du ein Statisches-Analys-Tool?
In beiden solltest Du erste Hinweise dazu finden, wofür Misra gut ist, dass man nicht alle Regeln blind einhalten soll, auch nicht die verpflichtenden und was man sonst noch dazu braucht.
BTW.: wofür „brauchst“ Du es denn?
Hi und danke für Deine Antwort auf meine Frage bzgl. MISRA.
Ich bin im Prinzip auf der Suche nach Best Practices von „erfahrenen Hasen“, welche MISRA-Regeln wirklich Sinn machen und welche nice-to-have oder in der Praxis eher negativ sind? Das Handbuch habe ich mir gekauft und ich musste feststellen, dass es weit mehr als 10 Regeln gibt 
MISRA ist ja im Automotive-Bereich stark vertreten und wenn man dort entwickelt, sollte man nach MISRA arbeiten. Aber macht es Sinn jede Regeln anzuwenden?
Gruß
AXL
Misra ist vor allem für Anfänger gedacht, die die Eigenheiten der Sprache C und die Möglichkeiten von Lint & Co noch nicht kennen. Die Regeln machen alle Sinn. Wenn man den ergründen und einordnen kann, dann kann man die Regeln auch brechen. Aber nicht einfach so, sondern abgestimmt im Team mit festem Prozedere.
Der Kunde (Manager, Auftraggeber, Prüfer) kann dann relativ schnell sehen, welche und wieviele Regelabweichungen vorkommen.
Bei der Einführung sollte zumindest ein erfahrender C-Programmierer dabei sein.
Hallo AXL,
Wie schon geschrieben wurde, sind es Regeln für Anfänger!
Grundsätzlich ist aber C keine Sprache für Anfänger, die Sprache wurde entwickelt um ein Betriebssystem zu entwickeln. Daher muss sie Bit-Fummeleien in zeitkritischen Hardware Treibern genau so effizient lösen können wie auch eine reine Anwendung.
Man kann in C viel Mist bauen, muss das aber nicht.
Allerdings kann man auch in Assembler strukturiert und Objekt-Orientiert programmieren!
Welche Regeln sinn mache oder nicht, kommt auf die Aufgabe an.
Ich habe in 25 Jahren C etwa 3x goto verwendet. Bei komplexen Fehlerbehandlungen geht es manchmal nicht ohne.
Die Portabilität-Forderung eines Hardware-Treibers bei einem Embedded-System zeigt, dass da jemand keine Ahnung hat. Solcher Code ist meistens schon bei einem anderen µC der selben Familie nicht wieder verwendbar.
Eine ganz anderes Problem ist dann die wirkliche Portierbarkeit Architekturnaher Software. Ich habe viele Übertragungsprotokolle geschrieben, welche dann auf einem µC und einem IBM-PC verwendet wurden. Ein Problem dabei ist, dass man Little und Big Endian hat, aber alles byteweise übertragen muss. Hat man für das Protokoll nur eine Source-Datei ist die Pflege wesentlich einfacher.
Manche Programmierer schaffen dies dann nur mit bedingter Compilierung, aber dann hat man eigentlich zwei Programme in einer Datei. Man kann das Zerstückeln und Zusammensetzen auch so schreiben, dass der Endian-Typ keine Rolle spielt. Vernünftige Compiler optimieren den Overhead dann sowieso weg!
Die Optimierung ist auf Hardware-Ebene sowieso ein Problem. Je nach dem was der Compiler so macht, ist dann das Timing ein anderes.
Regeln helfen sicher am Anfang, Wenn man aber weiss, welcher Code auf Assembler-Ebene erzeugt wird, ergeben sich viele Regeln von selbst und man weiss auch genau, wo sie nicht gelten.
MfG Peter(TOO)
1 Like