Ist Misra-C sinnvoll?

branch from: http://www.c-plusplus.net/forum/viewtopic-var-t-is-203319-and-start-is-80.html

Tim schrieb:

jammer-freak schrieb:

naja, dieses 'misra-c' ist anscheinend dafür da

"Anscheinend". Das ist deine Interpretation. Vielleicht ist es aber auch dafür da gern gemachte Fehler zu vermeiden? Oder vielleicht ist es auch dafür da um einen einheitlichen Stil unter hundertschaften von Entwicklern zu garantieren?
Das mag dich als perfekten Entwickler (mit ein paar Schwächen im Typsystem) vielleicht nicht tangieren. Aber nicht jeder arbeitet in einer 3-Mann-Klitsche wo der Entwicklungsprozess mit der Kaffee-mach-Liste schon hinreichend definiert ist.

meine interpretation war zwar nicht 100% treffend, aber auch nicht völlig falsch. bei der fliessbandmässigen softwareproduktion mit hundertschaften von entwicklern gibts natürlich 'ne menge leute, die ihr handwerk eben nicht so toll beherrschen. diesen misstand versucht man mit zeugs wie 'misra-c' wieder auszugleichen, allerdings zum nachteil der 'guten' entwickler, die sich nicht frei entfalten können (wobei ein guter entwickler niemals in einer solchen, misrc-geknechteten hundertschaft dienst tun würde, allerhöchstens temporär, als studentenjob o.ä).

btw. Tim, wieso reagierst du in letzter zeit immer so genervt? früher hast du wenigstens noch gewarnt und nicht einfach threads geschlossen, so dass keiner mehr antworten kann?

supertux

Zum Glück musste ich nie mit solchen (für mich) dunmmen Regeln wie Misra-C arbeiten. Ich würde auch kein Geld dafür zahlen, dass meine tägliche C Programmierarbeit erschwert wird. Ich verstehe wirklich nicht, was für'n Sinn es macht. Bei meinem Team haben wir uns geeinigt, wie wir unseren Code schreiben und haben uns auch die Sachen so aufgeteilt, dass Entwickler A an sich die Sachen von Entwickler B nicht weiterentwickeln soll und umgekehrt. Gut, wir sind auch nicht so viele, bei uns klappt es so wunderbar.

zeigerzeiger

branching-freak schrieb:

... bei der fliessbandmässigen softwareproduktion mit hundertschaften von entwicklern gibts natürlich 'ne menge leute, die ihr handwerk eben nicht so toll beherrschen. diesen misstand versucht man mit zeugs wie 'misra-c' wieder auszugleichen, allerdings zum nachteil der 'guten' entwickler, die sich nicht frei entfalten können ...

Das sehe ich anders... Genau das freie Entfalten von guten Entwicklern führt dann nämlich dazu, dass dann irgendwo im Projekt Seiteneffekte auftreten. (Hab ich selbst schon erlebt).

supertux schrieb:

Zum Glück musste ich nie mit solchen (für mich) dunmmen Regeln wie Misra-C arbeiten. Ich würde auch kein Geld dafür zahlen, dass meine tägliche C Programmierarbeit erschwert wird. Ich verstehe wirklich nicht, was für'n Sinn es macht.

Schon mal dran gedacht, dass dein Kunde Code fordert der dem MISRA - C Standard entspricht... (Sicherheitskritische Apps oder ähnliches. Im Automotive Bereich normalerweise auch Pflicht...)

supertux schrieb:

Bei meinem Team haben wir uns geeinigt, wie wir unseren Code schreiben und haben uns auch die Sachen so aufgeteilt, dass Entwickler A an sich die Sachen von Entwickler B nicht weiterentwickeln soll und umgekehrt. Gut, wir sind auch nicht so viele, bei uns klappt es so wunderbar.

Da würd mich dann mal interessieren, wer die Wartung des Codes von Entwickler A übernimmt, wenn der die Firma verlassen hat. Im schlechtesten Fall, kann man den Code gar nicht mehr nachvollziehen und muss den dann neu entwicklen...

supertux

zeigerzeiger schrieb:

Schon mal dran gedacht, dass dein Kunde Code fordert der dem MISRA - C Standard entspricht... (Sicherheitskritische Apps oder ähnliches. Im Automotive Bereich normalerweise auch Pflicht...)

wir verkaufen keine Software, unsere Software wird auschließlich intern benutzt. Also müssen wir uns diesbezgl. keine Gedanken machen

Und apropo Kunde: was für Kunden meinst du? Ein Kunde, der nur die Software einsetzt, wird sich bestimmt nicht dafür interessieren, nach welchen Code Standard deine Software geschrieben wurde. Wenn dein Kunde deine Bibs benutzt, dann musst du ehe sowieso deine API/ABI gut dokumentieren. Klar, der Kunde ist der König, aber ich sehe ehrlich gesagt kein Gewinn, indem man die Programmierarbeit durch dumme Einschränkungen erschwert.

zeigerzeiger schrieb:

Da würd mich dann mal interessieren, wer die Wartung des Codes von Entwickler A übernimmt, wenn der die Firma verlassen hat. Im schlechtesten Fall, kann man den Code gar nicht mehr nachvollziehen und muss den dann neu entwicklen...

Allerdings. Diese Diskussion hatten wir schon mal und das ist eines der Themen, die wir immer wieder ansprechen.

rüdiger

Einheitliche Regeln sind sehr sinnvoll. Gerade in kritischen Projekten (Motorsteuerung, Herzschrittmacher etc.). Sicher kann man über die ein oder andere Regel streiten und oft werden sicher Glaubensfragen in Papier gegossen. Aber darüber streiten lohnt sich wohl nur beim nächsten Treffen des Standard Komitees. Wenn man Misra-C benutzen muss, kann man ja ah nicht anders, als sich damit abzufinden.

supertux

rüdiger schrieb:

Einheitliche Regeln sind sehr sinnvoll.

das ist klar, sehe ich genauso. Aber ich finde, dass manche Regel einfach sinnlos sind.

rüdiger schrieb:

Wenn man Misra-C benutzen muss, kann man ja ah nicht anders, als sich damit abzufinden.

Zum Glück muss *ich* nicht danach/damit arbeiten.

supertux schrieb:

...aber ich sehe ehrlich gesagt kein Gewinn, indem man die Programmierarbeit durch dumme Einschränkungen erschwert.

der gewinn besteht darin, dass auch entwickler ohne viel erfahrung code schreiben können, der nicht unterhalb einer gewissen qualitätsgrenze liegt. andererseits können versierte (und trotzdem verantwortunsgvolle) entwickler ihr können nicht voll ausspielen, weil der misrca-rules checker ewig meckert. sie müssen ihren programmierstil daran anpassen, werden dadurch total unproduktiv und sind nur noch genervt. ich finde misra-c voll mies. wer meint, dass C zu 'unsafe' für seine belange ist, der sollte besser eine andere sprache einsetzen (z.b. ADA oder ähnliches).

rüdiger schrieb:

Wenn man Misra-C benutzen muss, kann man ja ah nicht anders, als sich damit abzufinden.

doch, den auftrag nicht annehmen oder kündigen.

sothis_

straightness-freak schrieb:

rüdiger schrieb:

Wenn man Misra-C benutzen muss, kann man ja ah nicht anders, als sich damit abzufinden.

doch, den auftrag nicht annehmen oder kündigen.

dies sehe ich genau so. wenn mir prinzipiell etwas gegen den strich geht ziehe ich die konsequenzen. viele arbeitgeber verlassen sich immer noch zu sehr auf die angst vor der arbeitslosigkeit. ich persönlich würde mich weigern meinen programmierstil abändern zu müssen, wenn mir niemand auch nur einen plausiblen grund für die restriktion anführen würde. wenn der programmierer aber damit klar kommt, warum nicht. ob es der sicherheit und zuverlässigkeit der software zuträgt steht auf einem anderen blatt.

Bashar

sothis_ schrieb:

viele arbeitgeber verlassen sich immer noch zu sehr auf die angst vor der arbeitslosigkeit. ich persönlich würde mich weigern meinen programmierstil abändern zu müssen, wenn mir niemand auch nur einen plausiblen grund für die restriktion anführen würde.

Wow, starke Worte. Mich würde interessieren, ob du schonmal in so einer Situation warst oder überhaupt potentiell bist und nicht bloß rumblubberst. Dass einem im Job immer wirklich alles passt ist glaube ich doch eher selten.

Bashar schrieb:

Dass einem im Job immer wirklich alles passt ist glaube ich doch eher selten.

das ist klar, aber solche erscheinungen müssen vorübergehender natur sein. im grossen und ganzen muss es passen, sonst hat das ganze keinen sinn. ein programmierer, der erfüllung in seiner arbeit sucht, wird sich kaum mit misra-c anfreunden können. einer der denkt 'mir doch egal was ich hier mache, hauptsache es gibt kohle dafür' schon eher. ungeachtet der tatsache, dass ein ständiger, fliessbandmässiger job in einem team von misra-codern die persönliche, fachliche weiterentwicklung extrem hemmt und den eigenen wert auf dem arbeitsmarkt verringert (ausnahme: man möchte in der nächsten automotive-klitsche landen).

sothis_

Bashar schrieb:

sothis_ schrieb:

viele arbeitgeber verlassen sich immer noch zu sehr auf die angst vor der arbeitslosigkeit. ich persönlich würde mich weigern meinen programmierstil abändern zu müssen, wenn mir niemand auch nur einen plausiblen grund für die restriktion anführen würde.

Wow, starke Worte. Mich würde interessieren, ob du schonmal in so einer Situation warst oder überhaupt potentiell bist und nicht bloß rumblubberst.

ja, war ich, sehr oft sogar. meistens endet dies allerdings in einem lauten wortgefecht und am nächsten tag ist alles wieder in ordnung, so dass nach meinen vorstellungen weiterarbeiten kann. wiegesagt, wenn mir der sinn einleuchtend dargestellt wird, habe ich absolut kein problem damit regelwerke zu adaptieren. nur gelingt das den wenigsten chefs mit ihrem blinden pragmatismus

rüdiger

anti-misra-freak schrieb:

supertux schrieb:

...aber ich sehe ehrlich gesagt kein Gewinn, indem man die Programmierarbeit durch dumme Einschränkungen erschwert.

der gewinn besteht darin, dass auch entwickler ohne viel erfahrung code schreiben können, der nicht unterhalb einer gewissen qualitätsgrenze liegt. andererseits können versierte (und trotzdem verantwortunsgvolle) entwickler ihr können nicht voll ausspielen, weil der misrca-rules checker ewig meckert. sie müssen ihren programmierstil daran anpassen, werden dadurch total unproduktiv und sind nur noch genervt. ich finde misra-c voll mies. wer meint, dass C zu 'unsafe' für seine belange ist, der sollte besser eine andere sprache einsetzen (z.b. ADA oder ähnliches).

Ich gebe dir absolut recht. Strenge Regeln wie die von Misra-C sind unter anderem auch dafür da um Kreativität einzuschränken. Das ist natürlich frustrierend, wenn man schon lange programmiert. Ich mag es auch lieber nach meinen eigenen Regeln zu programmieren.

Aber ich sehe durchaus ein, dass ein kritisches Projekt hier gewisse Maßregeln treffen muss. Manchmal muss man einfach etwas den müseligen, langweiligen und nicht hippen Weg gehen, weil das Resultat einfach stabiler/resistenter ist. Und kritische Dinge, wie die Steuerung eines medizinischen Gerätes, eines Flugzeugmotors, eines Airbags oder einer ICBM, sollten dann vielleicht doch lieber langweilig aber dafür sicher/stabil entwickelt werden.

Wobei die Verwendung von ADA wohl durchaus zu empfehlen wäre :).

Aber wenn man sich so konsequent gegen Programmierrichtlinien wehrt, dann kann man wohl in derartigen Branchen nicht arbeiten. Zumindest in der Autoindustrie dürfte Misra-C doch Standard sein. (oder siehe die C++-Guidelines von Lockheed Martin).

Und wie Bashar schon gesagt hat. Lohnt es sich wirklich gegen so etwas zu wehren? Wer hat schon den 100% perfekten Job, wo es nie etwas gibt, was ihn stört?

sothis_

rüdiger schrieb:

Und wie Bashar schon gesagt hat. Lohnt es sich wirklich gegen so etwas zu wehren? Wer hat schon den 100% perfekten Job, wo es nie etwas gibt, was ihn stört?

dieser job exisitiert vermutlich nicht. ich habe aber gelernt, das es manchmal eben doch lohnt sich zu wehren insbesondere gegen umstände die für mich absolut sinnbefreit sind. am liebsten mag ich ja das argument "das haben wir schon immer so gemacht"

pointercrash**

Meine Erfahrungen mit MISRA sehen so aus:
In den frühen 90ern habe ich mal eine Bastelei abgeliefert, die im Wesentlichen als Protokollumsetzer gearbeitet hat, das waren ein paar Zeilen Assembler und weil's eine Insellösung war, hat sich niemand drum geschert. Später wurde das Ding um einen weiteren Bus aufgestockt und ich hab's mit einem Pascal neu gemacht, hat auch niemanden gejuckt. Letztes Jahr mußte die Sache aus technischen Gründen nochmal erweitert komplett neu designt werden, also in C, weil ein zugekaufter Netzwerkstack integriert werden sollte.

Bei der Abnahme sagte man mir alles schön und gut, aber ist es auch MISRA- konform? War mir völlig entgangen, aber Hausregel ist: Wenn C, dann nur MISRA. Hätte ich Pascal genommen, wärs ihnen wurscht gewesen, dann hätte ich aber den Stack selbst schreiben müssen.
Natürlich war's nicht konform. Nach dem Reformat- Lauf kommen einem manchmal auch eigene Module seltsam vor, weil man's optisch einfach anders im Gedächtnis hat. Natürlich wurden auch etliche Konstrukte bemängelt, die aber einwandfrei funktioniert haben.
Eine Totalkatastrophe war dann auch noch die zugekaufte Lib, wenn fremder Code MISRA- konform gemacht werden muß, muß man das ganze benörgelte Zeug auch verstehen.

Also der Umbau hat fast nochmal soviel Zeit gekostet wie das erste Design, ohne daß das in irgendeiner Weise produktiv war oder bezahlt wurde. Deswegen bin ich erstmal sauer auf das Beharren auf MISRA.
Ich bin seit 16 Jahren der Einzige, der an das Projekt hinpfuscht und wage zu behaupten, daß die Anlage durch MISRA weder wartbarer geworden ist noch an Stabilität gewonnen hat, an einigen Stellen sogar deutlich umständlicher.

Die Frage müßte lauten, ob es hier jemanden gibt, der sagt, fremden Code kapier' ich viel schneller, wenn er MISRA- konform geschrieben ist, dann hätte es einen Nutzen.

rüdiger

sothis_ schrieb:

rüdiger schrieb:

Und wie Bashar schon gesagt hat. Lohnt es sich wirklich gegen so etwas zu wehren? Wer hat schon den 100% perfekten Job, wo es nie etwas gibt, was ihn stört?

dieser job exisitiert vermutlich nicht. ich habe aber gelernt, das es manchmal eben doch lohnt sich zu wehren insbesondere gegen umstände die für mich absolut sinnbefreit sind. am liebsten mag ich ja das argument "das haben wir schon immer so gemacht"

Warum sind sie Sinnbefreit? Einheitliche Code-Regeln sind nun mal etwas praktisches, weil man sich auf gewisse Dinge verlassen kann. Das einarbeiten in Code von dritten geht schneller, da man gewisse Garantien hat und dadurch weniger Fehler macht. Ich würde eher sagen, dass das alles andere als Sinnbefreit ist.

sothis_

rüdiger schrieb:

sothis_ schrieb:

rüdiger schrieb:

Und wie Bashar schon gesagt hat. Lohnt es sich wirklich gegen so etwas zu wehren? Wer hat schon den 100% perfekten Job, wo es nie etwas gibt, was ihn stört?

dieser job exisitiert vermutlich nicht. ich habe aber gelernt, das es manchmal eben doch lohnt sich zu wehren insbesondere gegen umstände die für mich absolut sinnbefreit sind. am liebsten mag ich ja das argument "das haben wir schon immer so gemacht"

Warum sind sie Sinnbefreit? Einheitliche Code-Regeln sind nun mal etwas praktisches, weil man sich auf gewisse Dinge verlassen kann. Das einarbeiten in Code von dritten geht schneller, da man gewisse Garantien hat und dadurch weniger Fehler macht. Ich würde eher sagen, dass das alles andere als Sinnbefreit ist.

habe ich irgend etwas spezielles mit sinnbefreit tituliert?

Bashar

self-rule-freak schrieb:

automotive-klitsche

Heißt Embedded-Programmierung in Deutschland nicht automatisch zu 80% automotive?

sothis_ schrieb:

meistens endet dies allerdings in einem lauten wortgefecht und am nächsten tag ist alles wieder in ordnung, so dass nach meinen vorstellungen weiterarbeiten kann.

Das hört sich jetzt so an, als ob dein Chef eines Tages mit einer tollen Idee auf dich zugekommen ist, die du abgeschmettert hast. Aber wenn du in einen neuen Job kommst, in dem alles stimmt bis auf ein paar sinnbefreite Regeln, dann kündigst du nicht sofort wieder.

rüdiger schrieb:

Warum sind sie Sinnbefreit? Einheitliche Code-Regeln sind nun mal etwas praktisches, weil man sich auf gewisse Dinge verlassen kann. Das einarbeiten in Code von dritten geht schneller, da man gewisse Garantien hat und dadurch weniger Fehler macht. Ich würde eher sagen, dass das alles andere als Sinnbefreit ist.

Meiner Erfahrung nach erleichtern formale Coderichtlinien die Einarbeitung überhaupt nicht. Dabei kommt es nämlich nicht darauf an, zu erkennen, was der Code macht, sondern was der ursprüngliche Programmierer gemeint hat. Ordentliche Programmierer schaffen es auch so, verständlichen Code zu schreiben. Schlimm ist, dass solche Richtlinien nicht nur eine negative Aussage treffen, sondern effektiv auch eine positive: Dieser Code ist verständlich, weil er den Richtlinien entspricht. Dabei wissen wohl die meisten hier, dass die fiesesten Fallstricke überhaupt nicht durch formale Richtlinien abgefangen werden können.

Bashar schrieb:

self-rule-freak schrieb:

automotive-klitsche

Heißt Embedded-Programmierung in Deutschland nicht automatisch zu 80% automotive?

glaub' ich nicht. in der automatisierung, unterhaltungselektronik, telekommunikation usw. werden auch ohne ende kleinstrechner verbaut. kannst ja mal auf die 'embedded world' in nürnberg gucken gehen (ist ja im februar wieder).

marktschätzungs-freak schrieb:

kannst ja mal auf die 'embedded world' in nürnberg gucken gehen (ist ja im februar wieder).

Da freu ich mich schon drauf.

Bashar schrieb:

Schlimm ist, dass solche Richtlinien nicht nur eine negative Aussage treffen, sondern effektiv auch eine positive: Dieser Code ist verständlich, weil er den Richtlinien entspricht. Dabei wissen wohl die meisten hier, dass die fiesesten Fallstricke überhaupt nicht durch formale Richtlinien abgefangen werden können.

Ich glaube, das trifft es ziemlich gut
Ein paar Sachen sind zumindest strange bei MISRA:
Warum z.B.

rueckwert = function();
if (!rueckwert)
{
	// Fehlerbehandlung(rueckwert);
}

besser sein soll als

if (rueckwert != 0)
{
	// Fehlerbehandlung(rueckwert);
...

soll, ist mir nicht klarzumachen . Explizite Prüfung gegen Null, wer macht das schon und warum? Ich gebe einfach einen errorlevel zurück und wenn der null ist, ist der auch boole Null, das ist halt unter C so.

Ans Eingemachte geht es aber, wenn man mit Funktionspointern herumhantiert. Ich habe so eine verkettete Eventhandlerliste implementiert, da wird alles als void* draufgeschoben, die aufzurufenden Funktionen (alle void(void)) und auch die Parameter als (void einer struct irgendwas. Jede aufgerufene Funktion holt sich aus der Liste den Pointer auf die Argumente und muß halt mit einem free() das Argumentepaket nach der Abarbeitung löschen, also eigentlich durchschaubar, aber nach MISRA stockverboten
Als Umgehungskonstrukt ist mir nur eingefallen, Event- IDs in eine Liste zu schieben und die über eine lange switch/case zu parsen. Vorher war's sowohl übersichtlicher als auch performanter. Glaube nicht, daß jemand nach der MISRA- Adaption sagen könnte: "Das kapier' ich schneller".

Alle Hardwarezugriffe auf ein File zu konzentrieren ist ja auch Unsinn, eine per #include zugebundene Funktionssammlung sollte per einfachem #define im Header schon von sich aus wissen, ob sie jetzt für einen SH8 oder einen AVR compiliert wird. Das Zentralisieren hat zumindest in der Geschichte (s.o.) einen nicht wiederverwertbaren S*c*e*ecode ergeben und nach dieser Abnahme will ich nie wider über MISRA nachdenken müssen.

Also, gibt es jetzt jemanden, der den MISRA- Kram total toll findet oder nicht?

Tim schrieb:

Da freu ich mich schon drauf.

Ich muß auch leider hin. Hey, Du Supermod, wegen so OT- Gequassel hast Du schon andere Topics geschlossen.