Ist Misra-C sinnvoll?

[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.

[self-rule-freak]

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.

[marktschätzungs-freak]

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).

[Gast]

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.

[OT-Quassler]

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.

[Gast]

OT-Quassler schrieb:

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.

Hallo pointercrash(). Spar dir doch bitte solche Provokationen. Ich habe dir angeboten unseren Konflikt (den wir ja unbestritten haben) in aller Ruhe zu klären. Solche Kommentare sind einfach nur unnötig.