Newsgroups: de.comp.lang.c Von: Rainer Weikusat Datum: Thu, 18 Mar 2004 10:27:00 +0100 Betreff: Re: MISRA-Standard Quellen? Vinzent 'Gadget' Hoefler writes: > Rainer Weikusat wrote: >>"R.Freitag" writes: >>> Der MISRA-Standard definiert bestimmte, der Robustheit und Wartbarkeit >>> fördernde Richtlinien zur Programmierung in C. >>Nein. > Naja, einiges wuerde ich zumindest als brauchbar bezeichnen. Das schließt sich nicht aus. > |Only expressions concerned with loop control should appear within a > |for statement. > Komisch finde ich eher, dass man so was in speziellen Guidelines > schreiben muss und das nicht generell zum common sense gehoert. Deswegen halte ich das Verfahren auch für 'eher unsinnig': Gesetzt den Fall, es gäbe tatsächlich jemand, dem man solche Anweisungen an die Hand geben muß, um Unbill zu verhüten: Kann ich in endlicher Zeit eine 'wasserdichte' Richtlinie für sowas verfassen oder ließe sich das vielleicht unaufwendiger lösen, in dem ich ihm/ihr einen Lolli oder sonst etwas nettes, buntes und harmloses in die Hand drücke, und die eigentliche Arbeit selber mache? Und wie schütze ich den Inhalt dieser Richtlinie davor, zB als vollkommen gegenteilig zur ihrer Intention 'interpretiert' zu werden? Menschen sind ziemlich gut darin, plausibel scheinende Gedankengebäude zu errichten, die einen a priori feststehenden Standpunkt 'begründen'. Hinzu kommt noch, daß Stilvorschriften auf statement-Ebene niemanden daran hindern, Zehntausendzeilen-'Skripte' (was scheinbar viele Leute unter 'Programmen' verstehen) mit der Binnenstruktur eines Knorpels zu verfassen. Gröbere Anweisungen wie 'ein dokumentierter Entwurf wird erstellt' halte ich da für sinnvoller (was natürlich 'in der Praxis' mit 'Warum muß das dokumentiert werden, solange das GUI stabil läuft' kolldiert :-( ).
Newsgroups: de.comp.lang.c Von: Rainer Weikusat Datum: Fri, 19 Mar 2004 23:12:50 +0100 Lokal: Fr. 19 Mrz. 2004 17:12 Betreff: Re: MISRA-Standard Quellen? "Herbert Rosenau" writes: > Wenn Menschenleben an einem winzigen Fehler hängen können, können > Regeln nicht scharf genug sein. Das ist vollkommener Bullshit. Produktqualitaet erreicht man nicht durch drakonisches tyrannisieren der 'Produzierenden', sondern durch eine Qualitaetskontrolle anhand objektiv ueberpruefbarer Kriterien. Dazu zaehlt nicht subjektive Vorlieben irgendwelcher Personen fuer ihre eigenen Geistesprodukte, wie zB projektierte Programmierpsrachen, fuer die es noch nicht mal Compiler gibt. [...] > steigert die Sicherheit des Codes auch noch ein wenig. Falls Du die 'Sicherheit' von Code steigern moechtest, solltest Du ihn verschluesseln. Das was Du allerdings meinst, ist binaer: Vorhandensein von Fehlern, die bestimmte Konsequenzen haben. Die sind entweder vorhanden, oder sie sind das nicht. Die Frage laesst sich beantworten und falls die Anwort 'ja' lautet, spielt die Wahrscheinlichkeit, mit der nach Massgabe von $unquantifizierbare_kriterium danach zu rechnen geswesen ware, das die Antwort ja gelautet haette, falls jemand sich die Muehe gemacht haette, das zu ueberpruefen, keine Rolle. > Man wird gezwungen an den else Zweig zu denken und den auch > auszuformulieren - und wenn mit einem leeren statement. Wenn x dann tue blah, andnernfalls ... ups ... ismirnursorausgerutscht?
Newsgroups: de.comp.lang.c Von: Rainer Weikusat Datum: Sat, 20 Mar 2004 01:04:12 +0100 Lokal: Fr. 19 Mrz. 2004 19:04 Betreff: Re: MISRA-Standard Quellen? "Ralf Neuber" writes: > Wann immer eine Behörde wie TÜV, BiA eingeschaltet werden muss zur Abnahme > der Software werden diese Regeln erwartet. HIS ist denke ich der selbe Weg. > Schliesslich werden ja so viele Prozesse ausgelagert auf Zulieferer, dass > man ganz einfach eine gewisse Form definieren muss. Die 'gewisse Form' ist aber bereits definiert, naemlich in der Sprachdefinition. Falls jemand eine 'gewisse andere Form' moechte, sollte er das sinnvollerweise so machen, einen Compiler zu implementieren, der die Einhaltung dieser Form gewaehrleistet, *anstatt* einem Menschen, der ohnehin schon von alleine Fehler machen wird, noch zusaetzlich mit dem Auswendiglernen und Beachten sachfremder Vorschriftenkataloge zu belasten. Dadurch wird der naemlich *mehr* Fehler machen, anstatt weniger, weil er mehr Entscheidungen treffen muss. > Selbst wenn manche Regeln von MISRA bei einem Release bewusst gebrochen > werden -> wenn es begründet+logischerweise geschieht hat keiner was > dagegen. Eine 'Regel', die man 'logisch und begruendet' brechen kann, ist unzulaenglich und somit auch unsinnig. > In der Realität: Es gibt den Techniker(passt schon) und den > Sicherheitsfanatiker(ui, das muss aber alles mindestens redundant sein) und > den Jurist(wenn was passiert...) und den Wirtschaftler(billig muss es > schein) und ... - das alles vernünftig unter einen Hut zu bringen ist > schwer. Deshalb ist es gut Regeln aufzustellen die das Grundgerüst > bilden. Aus naheliegenden werden die technischen Anteile von Reaktorsicherheitsbestimmungen *nicht* von Juristen, Wirtschaftlern, Salesfraggles und Kabelziehern, die alle die Eigenschaft 'unqualifiziert' haben, untereinander ausgekungelt (vermutlich werden sie das doch :->>).
Newsgroups: de.comp.lang.c Von: Rainer Weikusat Datum: Mon, 22 Mar 2004 05:08:03 +0100 Lokal: So 21 Mrz. 2004 23:08 Betreff: Re: MISRA-Standard Quellen? "Herbert Rosenau" writes: [...] >> > Weikusat zeigt einmal mehr daß er nichts als Luftblasen produziert. >> > Ahnung von dem über das er quasselt hat er jendenfall keine. >> Woher willst du das wissen? [...] > Google nach weikusat. >> Das ist vollkommener Bullshit. Produktqualitaet erreicht man nicht >> durch drakonisches tyrannisieren der 'Produzierenden', sondern durch >> eine Qualitaetskontrolle anhand objektiv ueberpruefbarer >> Kriterien. Dazu zaehlt nicht subjektive Vorlieben irgendwelcher >> Personen fuer ihre eigenen Geistesprodukte, wie zB projektierte >> Programmierpsrachen, fuer die es noch nicht mal Compiler gibt. > erzählt der Quatschkopp der ANSI für überflüssig hält. 'Scharfe Regeln' sind nicht dasselbe wie 'gründliche Kontrollen'. Damit darfst Du Dich inhaltlich auseinandersetzen, falls Du dazu imstande bist. Pöbeln kann jeder. [...] Das läuft immer noch darauf hinaus, daß alle Leute, die dieselben Vorurteile haben wie Du, aus denselben Fakten identische Schlußfolgerungen ziehen werden, es sich also erübrigt, im Detail darauf einzugehen, *worauf* Du Dich eigentlich beziehst, weil alle, 'die des rechten Sinnes sind' ohnehin mit Dir übereinstimmen und alle anderen das eben nicht sind. Es stellt sich allerdings die Frage, warum etwas, das so offensichtlich unsinnig ist (Deiner Meinung nach), wie das, was ich geschrieben hatte, sich nicht auch einfachst sachlich widerlegen lassen sollte. Es sollte das dann nämlich. Also bitte. Ich poste nochmal ein stilmittelfreie Zusammenfassung, damit es auch für leicht reizbare Leute etwas einfacher wird, den Kern der Aussage zu erkennen, und nicht nur den Widerspruch als solchen. 1. Die Aussage 'wenn Menschenleben an einem winzigen Fehler hängen können, können die Regeln nicht scharf genug sein' ist ein Allgemeinplatz ohne Inhalt. Zum einen sind unsachliche Vorschriften nicht deswegen 'scharf', weil sie unsachlich sind, sondern sie sind genauso wie 'scharfe Regeln' (was auch immer das sein mag) auch lästig, lediglich für eine andere Sorte von Leuten: 'Scharfe Regeln' sind eine Belästigung für Leute, die gerne schlampen, solange ihnen dafür niemand auf die Finger haut (Du redest von Dir? Oder von Deinen Kollegen? Oder - in diesem Fall herzliches Beileid an deren Adresse - von Untergebenen?). Unsachliche Regeln sind eine Belästigung für Leute, die versuchen, ordentliche Arbeit zu leisten. Eine 'scharfe Regel' in diesem Sinne wäre zum Beispiel die Forderung, das grundsätzlich eine schriftliche Spezifikation erstellt wird, und Implementierungen grundsätzlich brauchbar dokumentiert werden. 'In der Praxis' scheitert die erste Forderung daran, das diese auch niemand verstünde, der nicht auch mit der Materie befaßt ist, nach Maßgabe der Abteilungen 'Vertrieb', 'Support' und 'Marketing' handelt es sich also um Zeitverschwendung, die zu unterbleiben hat, wer es also nicht ohne 'kann', ist für seinen Job nicht ausreichend qualifiziert (ich generalisiere meine Arbeitssituation, und während ich zum Glück nicht für Menschenleben verantwortlich bin, könnte ich aber mittelbar erhebliche finanzielle Verluste verursachen. Deswegen wird mir aber trotzdem niemand freiwillig irgendwelche Zeit für 'Planung' zubilligen, erst recht nicht insofern das auch noch Dritte 'vom Arbeiten abhalten würde'). Die Regel alleine bringt gar nichts, solange sie nicht konsequent umgesetzt wird. Analog verhält es sich mit dem zweiten Teil. Hierzu erlaube ich mir eine Paraphrase eines Kollegen: 'Wenn ich wüßte, wie das geht, müßte ich es am Ende noch selber tun', ergo: Keine Dokumentation. Sie wird als Belästigung oder als 'sich ohne Grund wichtig machen' empfunden, insbesondere von Leuten, die in einem der drei genannten Bereiche arbeiten, denn es macht ihnen mehr Arbeit und 'es geht ja auch so'. Die Forderung, kein if ohne else zu schreiben hingegen, ist unsachlich. Nehmen wir mal folgendes Codebeispiel: errno = 0; ul = strtoul(s, &tail, 10); if (errno) { /* handle error */; } if (*s && *tail) { /* invalid chars */; } /* everything is fine */ Es gibt hier keine 'else'-Zweige, an die man denken könnte, ausser, dass die Grammatik welche erlauben würde. Also ändern wir das mal so, um der Regel genüge zu tun: errno = 0; ul = strtoul(s, &tail, 10); if (errno) { /* handle error */ } else if (*s && *tail) { /* invalid */; } else { /* do something */; } /* and now? */ Wird der Code dadurch irgendwie 'besser'? Meiner Meinung nach nein. Also gut, nächster Versuch: errno = 0; ul = strtoul(s, &tail, 10); if (!errno) { if (!*s || !*tail) { /* 1 */ . } else { /* invalid */ } /* and what goes here? */ } else { /* error */ } /* and here? */ 1) Sowas haben wir doch hoffentlich alle im Kopf, ja? Oder direkt als Lippenbekenntnis: errno = 0; ul = strtoul(s, &tail, NULL); if (errno) { /* error */ } else ; if (*s && *tail) { /* invalid */ } else ; Damit ist der Kontrollfluß wieder 'einfach' verständlich. Aber welchen Sinn hat das? Antwort: Keinen. Es ist eine reine Idiosynkrasie, die auswendig gelernt und mechanisch befolgt werden muß 'weil das halt so ist'. Je mehr solcher 'unregelmäßiger Verben' ich einem Menschen aufbürde, desto mehr intellektuelle Kapazität muß dieser für immanent un-sinniges aufwenden. Keine schlaue Strategie, falls man diese als begrenzt akzeptiert. 2. 'xy steigert die Sicherheit des Codes' ist eine Aussage ohne Inhalt, denn es fehlt der Bezug: Was ist sicher vor wem oder wer ist sich wessen sicher? Der Begriff ist nicht steigerbar: Ich bin mir einer Tatsache entweder sicher, oder ich bin das nicht. Ein Bremssystem, das nur in fünf von hundert Fällen beschleunigt anstatt zu bremsen, ist nicht 'sicherer' als eines, das das in dreißig von hundert fällen tut. Es bietet statistisch größere Überlebenschancen, wird aber mit Sicherheit zum Tode von irgendjemand führen, falls man es lange genug darauf ankommen läßt, und eventuell schon beim ersten Mal. Und jetzt möchte ich bitte mal etwas lesen, das sich nicht ausschliesslich auf Gesetzesübertretungen beschränkt, Herr 'Scharfe Regeln für Andere !!1'.
Newsgroups: de.comp.lang.c Von: Rainer Weikusat Datum: Mon, 22 Mar 2004 10:38:32 +0100 Lokal: Mo 22 Mrz. 2004 04:38 Betreff: Re: MISRA-Standard Quellen? Bernd Nawothnig writes: [...] > Es ist natürlich in einigen hier mit Recht erwähnten Fällen > illusorisch, eine perfekt angepasste Sprache zu erwarten. In solchen > Fällen können Konventionen immerhin die Fehlerwahrscheinlichkeit > reduzieren, wenn man gezwungen ist in einer für das Problem > eigentlich ungeeigneten Sprache zu programmieren. Es gibt einen durch nichts zu erschuetternden Glauben daran, das man von einer bestimmten Personengruppe haeufig gemachten sprachlichen Fehlern dadurch beikommen koenne, das man die Sprache um die Konstrukte bereinigt, bei deren Verwendung in der Vergangenheit Fehler gemacht wurden. Am besten illustiert ist das in '1984': Wenn die Menschen nichts 'falsches' mehr denken koenne, weil sie keine Begriffe mehr dafuer haben, denken sie nur noch 'richtig'. Das laesst allerdings die Moeglichkeit kreativer Sprachnutzung vollkommen ausser acht, sowohl, insoweit es Inhaltliches betrifft, als auch fuer 'Sprachfehlnutzung'. Das 'konventionelle' Verfahren (beim Erlernen natuerlicher Sprachen) waere, problematische Konstrukte zu trainieren. Von Fremdsprachenkorrespondenten wird erwartet, die Sprache(n), in der/denen sie korrespondieren, zu erlernen. Warum nicht auch von Programmierern? >>> Selbst wenn manche Regeln von MISRA bei einem Release bewusst gebrochen >>> werden -> wenn es begründet+logischerweise geschieht hat keiner was >>> dagegen. >> Eine 'Regel', die man 'logisch und begruendet' brechen kann, ist >> unzulaenglich und somit auch unsinnig. > Sie wird zumindest fragwürdig. So drastisch wie Du sehe ich das aber > nicht. Ich bin einfach nicht ueberzeugt davon, dass es hilfreich ist, Leute dazu zu zwingen, sich Gedanken ueber Dinge zu machen, ueber die sie sich Gedanken machen sollten.
Newsgroups: de.comp.lang.c Von: Bernd Nawothnig Datum: Mon, 22 Mar 2004 11:37:21 +0100 Lokal: Mo 22 Mrz. 2004 05:37 Betreff: Re: MISRA-Standard Quellen? Hi Rainer, On Mon, 22 Mar 2004, Rainer Weikusat wrote: >> Es ist natürlich in einigen hier mit Recht erwähnten Fällen illusorisch, >> eine perfekt angepasste Sprache zu erwarten. In solchen Fällen können >> Konventionen immerhin die Fehlerwahrscheinlichkeit reduzieren, wenn man >> gezwungen ist in einer für das Problem eigentlich ungeeigneten Sprache zu >> programmieren. > Es gibt einen durch nichts zu erschuetternden Glauben daran, das man von > einer bestimmten Personengruppe haeufig gemachten sprachlichen Fehlern > dadurch beikommen koenne, das man die Sprache um die Konstrukte bereinigt, > bei deren Verwendung in der Vergangenheit Fehler gemacht wurden. Am besten > illustiert ist das in '1984': Wenn die Menschen nichts 'falsches' mehr > denken koenne, weil sie keine Begriffe mehr dafuer haben, denken sie nur > noch 'richtig'. Das laesst allerdings die Moeglichkeit kreativer > Sprachnutzung vollkommen ausser acht, sowohl, insoweit es Inhaltliches > betrifft, als auch fuer 'Sprachfehlnutzung'. Das 'konventionelle' > Verfahren (beim Erlernen natuerlicher Sprachen) waere, problematische > Konstrukte zu trainieren. Von Fremdsprachenkorrespondenten wird erwartet, > die Sprache(n), in der/denen sie korrespondieren, zu erlernen. Warum nicht > auch von Programmierern? Ich verstehe schon, was Du meinst und stimme Dir durchaus zu. Nun habe ich aber auch schon diverse Programmierkurse geleitet oder betreut und da sind gewisse Guidelines einfach besser, natürlich mit dem expliziten Zusatz, dass es nur solche sind, da lege ich immer Wert drauf. Aber speziell was das goto angeht, habe ich da im Zweifelsfall ähnlich ketzerische Ansichten wie Du. Es ist Bestandteil der Sprache und darf deswegen selbstverständlich verwendet werden. Allerdings empfehle ich Anfängern, sich erstmal zu überlegen, ob man das Problem nicht anders und dann auch besser verständlich formulieren kann. Betonung ist da auch immer, den _Vorzug_ anderer Konstrukte zu zeigen.
Newsgroups: de.comp.lang.c Von: Rainer Weikusat Datum: Thu, 25 Mar 2004 21:09:29 +0100 Lokal: Do 25 Mrz. 2004 15:09 Betreff: Re: MISRA-Standard Quellen? "Ralf Neuber" writes: >> > Selbst wenn manche Regeln von MISRA bei einem Release bewusst gebrochen >> > werden -> wenn es begründet+logischerweise geschieht hat keiner was >> > dagegen. >> Eine 'Regel', die man 'logisch und begruendet' brechen kann, ist >> unzulaenglich und somit auch unsinnig. > Hmm, glaube ich nicht ganz so. Manchmal kommt man in einer bestimmten > Konstellation nur mit dem Brechen einer Regel zum Ziel. Dabei die Regel > grundsätzlich gleich in frage stellen.... Ohne eine konkrete Regel hängt das etwas in der Luft, deswegen erlaube ich mir mal ein Beispiel: 'Non-constant pointers to functions shall not be used' (Paraphrase). Das läuft auf 'pointers to functions shall not be used' hinaus, respektive darauf, eine strikte Unterscheidung zwischen 'passiven' Daten und 'aktivem' Code zu haben. Falls ich irgendeine Form von OO benutzen moechte (und ich moechte das), wuerde diese Regel das untersagen. Ich kann jetzt 'begründet' darauf verzichten, aber dann habe ich 'non constant pointer to functions shall only be used where appropriate', was zwar sicher richtig ist, aber ein Allgemeinplatz. Eine schoene Formulierung aus dem 'Camel book' (heute Mittag auf der Arbeit gelesen): The optimizer makes no attempts to move invariant code out of loops. It expects you *to exercise some sense*. Man sollte die Sinnhaftigkeit eigener Kreationen kritisch hinterfragen obwohl es 'eigene' sind. Das bringt meiner Meinung nach mehr, als der Versuch, 'Missgeburten' 'statisch' zu verhindern.
Newsgroups: de.comp.lang.c Von: Bodo Thiesen Datum: Sun, 21 Mar 2004 21:52:14 +0100 Lokal: So 21 Mrz. 2004 15:52 Betreff: Re: MISRA-Standard Quellen? jos...@bigfoot.de (Jochen Schoof) wrote: > Stefan Reuther wrote in message ... >> 47 "No dependence should be placed on C's operator procedence(sic!) >> rules in expressions" >> (damit werden alle Ausdrücke verboten, die nicht die Form >> 'a = b' oder 'a += b' haben, da ja 'a = b + c' sich darauf verläßt, >> dass '+' einen geringeren Rang als '=' hat) > MISRA sieht = offenbar nicht als Operator an, denn das Beispiel > zur Anwendung von Regel 47 lautet "x = (3 * a) + (b / c);" :-) Wir dürfen also zusammenfassen. Eine Gruppe von Leuten, die die Sprache C nicht verstanden haben, stellen Richtlinien auf, was man (nicht) machen muß/soll/darf, um möglichst "robusten" C-Code zu schreiben ... >Lustiger sind meines Achtens einige Kombinationen von Regeln: >1.) All code shall conform to ISO 9899 standard C, with no > extenxsions permitted. >9.) Comments shall not be nested. >Doppelt genäht hält besser... ;-) s.o. (das war mir nämlich auch gleich aufgefallen, und dürfte wiederum Grund für Regel 10 "Sections of code should not be commented out" sein, da in diesem Code-Bereich durchaus Kommentare liegen können.) Witzig finde ich dann aber auch das Verbot von break und continue. Gruß, Bodo
Newsgroups: de.comp.lang.c Von: Stefan Reuther Datum: Thu, 18 Mar 2004 22:36:50 +0100 Lokal: Do 18 Mrz. 2004 16:36 Betreff: Re: MISRA-Standard Quellen? Herbert Rosenau wrote: > On Thu, 18 Mar 2004 14:34:11 UTC, Stefan Reuther >>Ansonsten sind da einige weitere seltsame Regeln drin: >>10 "Sections of code should not be commented out" >> (wie 'deaktiviert' man dann ein Stück Code?) > #if 0 > #endif [...] > In sicherheitsrelevantem Code ist Klarheit wichtiger als Kompaktheit. > ein > if (x) blah(); > else ; > kann einer Menge Überraschungen vorbeugen. Sieht zwar ziemlich > unsinnig aus aber wehe dieser if wird in eine weitere Schatel gesteckt Definiere "Klarheit". Zu viele 'if' und zu viele Klammern sind auch wieder ungesund, weil man dann vor lauter Rauschen nicht sieht, was der Code macht. > Automatisierte Codeinspektion wird dadurch ein bißchen einfacher UND > steigert die Sicherheit des Codes auch noch ein wenig. Man wird > gezwungen an den else Zweig zu denken und den auch auszuformulieren - > und wenn mit einem leeren statement. Dokumentiert daß man auch an die > (überflüssige) Alternative gedacht hat. Ich find's überflüssig. Bei Sachen wie if (input_changed()) recompute_values(); brauche ich keinen else-Zweig. IMHO gewinnt man durch jene Regel nichts. Die if/then/else-Mehrdeutigkeit tritt auch nicht auf, wegen "59 The statements forming the body of an if, else if, else, while, do... while or for statement shall always be enclosed in braces".
Newsgroups: de.comp.lang.c Von: Bernd Nawothnig Datum: Fri, 19 Mar 2004 03:24:09 +0100 Lokal: Do 18 Mrz. 2004 21:24 Betreff: Re: MISRA-Standard Quellen? Hi Herbert, On Thu, 18 Mar 2004 (UTC), Herbert Rosenau wrote: > Wenn Menschenleben an einem winzigen Fehler hängen können, können > Regeln nicht scharf genug sein. Dann sollte dies bei der Wahl der Sprache bitte berücksichtigt werden. Es ist unsinnig, mangelnde Restriktionen der Sprachdefinition durch Codekonventionen ersetzen zu wollen und dieses dann als "Sicherheit" zu bezeichnen. Siehe auch den absurden Vorschlag, alles zu klammern: wer Operatoren und deren Vorrang für schwer verständlich oder abwegig hält, sollte konsequenterweise auch eine funktionale Sprache wählen. Sowas gibt es ja nun u.a. aus dem Grund.
From: Rainer Weikusat Newsgroups: de.comp.lang.c Subject: Re: clang V3.2 Date: Fri, 06 Jul 2012 15:55:52 +0100 Stefan Reuther writes: > Naja..... Bei uns ist seit neuestem per ordre de mufti "-Wconversion" > angeschaltet. Heißt: entweder, mann sieht in dem Wust vor Warnungen das > Relevante in der Compilerausgabe nicht mehr, oder man sieht in dem Wust > von Casts das Relevante im Code nicht mehr. Aber MISRA will's halt so. Je nachdem wer wem einen Rat gibt oder zu geben versucht waere auch die Ausgabe 'Beten Sie das Vaterunser' als 'moeglicherweise hilfreich' anzusehen ...
http://www.c-plusplus.de/forum/203673-full pointercrash() Mitglied Benutzerprofil Anmeldungsdatum: 02.01.2005 Beiträge: 3058 Beitrag 11:26:41 26.01.2008 Titel: 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.