Kodierrichtlinien (Coding Guidelines) dienen dazu, Quellcode zu fördern, der verständlich, wartbar, testbar und möglichst fehlerfrei ist. Dieser Artikel beschreibt die regulatorischen Anforderungen an Kodierrichtlinien und gibt konkrete Beispiele.
Regulatorische Anforderungen an Kodierrichtlinien
Forderungen der Medizinprodukte-Richtlinie (MDD)
Die Medizinprodukterichtlinie MDD (93/42/EWG) fordert für Medizinprodukte, die Software enthalten oder eigenständige Software sind:
Bei Produkten, die Software enthalten oder bei denen es sich um medizinische Software an sich handelt, muss die Software entsprechend dem Stand der Technik validiert werden, wobei die Grundsätze des Software-Lebenszyklus, des Risikomanagements, der Validierung und Verifizierung zu berücksichtigen sind.
Im Falle einer gerichtlichen Auseinandersetzung dürfte ein Gutachter bestätigen, dass die Verwendung von Kodierrichtlinien (Coding Guidelines) zum „Stand der Technik“ zählt.
Forderungen der Medizinprodukteverordnung (MDR)
Die Medizinprodukteverordnung MDR (2017/745) fordert für Medizinprodukte, die Software enthalten oder eigenständige Software sind:
Bei Produkten, zu deren Bestandteilen Software gehört, oder bei Produkten in Form einer Software wird die Software entsprechend dem Stand der Technik entwickelt und hergestellt, wobei die Grundsätze des Software-Lebenszyklus, des Risikomanagements einschließlich der Informationssicherheit, der Verifizierung und der Validierung zu berücksichtigen sind.
Gleich wie bei der Medizinprodukte-Richtlinie dürfte im Falle einer gerichtlichen Auseinandersetzung ein Gutachter bestätigen, dass die Verwendung von Kodierrichtlinien (Coding Guidelines) zum „Stand der Technik“ zählt.
Forderungen der IEC 62304
Die gute Nachricht vorweg: Die IEC 62304 fordert keine Kodierrichtlinien. Sie fordert nur, dass Akzeptanzkriterien an die Software-Einheiten formuliert und geprüft werden müssen. Die IEC 62304 schreibt nur in einer Anmerkung: „Beispiele für Akzeptanzkriterien sind: […] Entspricht der Software-Code festgelegten Programmier-Verfahren und Codierungsnormen?“
Forderungen der FDA an Kodierrichtlinien
Ebenso fordert die FDA nicht, dass Kodierrichtlinien einzuhalten sind. Allerdings schreibt die FDA im Software Validation Guidance Document:
The software design specification should include: […] Development procedures and coding guidelines (or other programming procedures); […] Firms frequently adopt specific coding guidelines that establish quality policies and procedures related to the software coding process. Source code should be evaluated to verify its compliance with specified coding guidelines. Such guidelines should include coding conventions regarding clarity, style, complexity management, and commenting. Code comments should provide useful and descriptive information for a module, including expected inputs and outputs, variables referenced, expected data types, and operations to be performed. Source code should also be evaluated to verify its compliance with the corresponding detailed design specification. Modules ready for integration and test should have documentation of compliance with coding guidelines and any other applicable quality policies and procedures.
Fazit
Die Verwendung von Kodierrichtlinien ist nicht explizit gefordert. Sie stellt aber den Stand der Technik dar. Medizinproduktehersteller sollten daher Kodierrichtlinien (Coding Guidelines) nutzen. Konkrete Vorgaben wie eine Liste anzuwendender Coding Guidelines gibt es nicht.
Kodierrichtlinien (Coding Guidelines)
Beispiele
Generell können die Kodierrichtlinien folgende Aspekte adressieren:
- Formatierung: Einrückungen, Verwendung von Leerzeichen bzw. Tabulatoren, Leerzeilen usw.
- Metriken: Länge von Klassen, Methoden/Funktionen und Zeilen, Schachtelungtiefe, zyklomatische Komplexität, Anzahl atomarer Bedingungen, Anzahl Übergabeparameter usw.
- Dokumentation: Inline, Funktionen/Methoden, Klassen
- Namenskonventionen: Groß- und Kleinschreibung, sprechende Namen,
- Sonstiges: Variablendeklarationen, Fehlerbehandlung, Internationalisierung
Die obige Abbildung nennt ebenfalls Beispiele. Für plattformspezifische Kodierrichtlinien geben Ihnen die unten genannten Werkzeuge weitere Hinweise.
Coding Guidelines der NASA
Besonders in sicherheitskritischen Bereichen wie Bahnverkehr, Kraftwerke oder der Luft- und Raumfahrt existieren spezifische Vorgaben an die Programmierung. So listet Gerard J. Holzmann in „The Power of Ten – Rules for Developing Safety Critical Code“ folgende Best-Practices:
- Einfach Kontrollkonstrukte. Keine Goto-Programmierung, keine Rekursion.
- Alle Schleifen müssen eine feste Obergrenze haben.
- Keine dynamische Speicherzuweisung nach der Initialisierung
- Keine Methode ist ausgedruckt länger als eine Seite
- Mindestens zwei „Assertions“ pro Methode/Funktion
- Objekte müssen möglichst lokal deklariert sein. Globale Variablen sind das Gegenteil dessen.
- Rückgabewerte von non-void Funktionen müssen ausgewertet werden
- Der Einsatz von Präprozessoren ist auf das Einschließen von Header-Files und einfache Makro-Definitionen zu beschränken
- Der Einsatz von Pointern ist einzuschränken
- Aller Code muss von Beginn an mit den strengsten Compiler-Warnungen kompiliert werden
Diese Liste lässt erkennen, dass der Autor eher die Sprache C im Hinterkopf hat, als eine .NET-Sprache oder Java.
Sinn von Kodierrichtlinien
Die Kodierrichtlinien verfolgen im Wesentlichen folgende Ziele:
- Sie sollen die Lesbarkeit, Verständlichkeit, Änderbarkeit und damit die Wartbarkeit des Codes erhöhen. Laut FDA fallen 79% der Fehler (und Aufwände?) in dieser Phase an.
- Sie sollen Fehler im Code (von Beginn an) minimieren.
- Die Effizienz und Effektivität von Code-Reviews verbessern (und damit wieder die Güte des Codes)
Kodierrichtlinien vereinfachen Code-Reviews
Beim Code-Review sollen Fehler gefunden werden. Diese Reviews sind besonders dann effektiv und effizient, wenn der Reviewer sich nicht in die spezifische Denkwelt des Entwicklers eindenken muss. Code-Reviews haben etwas mit „Pattern Recognition“ zu tun. Reviewer müssen den Code ansehen und sofort – sogar unbewusst – wahrnehmen können, wo etwas nicht stimmt – wo etwas faul ist.
Gute Entwickler können das. Das klappt aber nur, wenn der innere Algorithmus zur Mustererkennung immer das gleiche Input-Signal bekommt. Und dazu gehören Kodierrichtlinien, v.a. Formatierungen wie Klammersetzungen, Leerzeichen, Einrückungen usw. Andernfalls läuft der Algorithmus ins Leere. Genauso wäre das bei meiner Friseurin, hätte man die Bilder nicht weiß auf schwarz, sondern schwarz auf weiß oder rechts-links-vertauscht angezeigt.
Beispiel: Apples SSL-Bug
Die Wogen schlugen hoch wegen des Apple SSL-Bugs. Das verwundert ob der Schwere nicht. Eine nicht funktionierende Prüfung der Zertifikate untergräbt das komplette Sicherheitskonzept.
Man kann aus diesem Zwischenfall die Lehre ziehen, dass Kodierrichtlinien und Formatierungsrichtlinien sinnvoll und meines Erachtens verbindlich sein sollten. Dieser Fehler wäre nämlich mit hoher Wahrscheinlichkeit auch ohne Test(!!) aufgefallen, hätte man gefordert, dass
- Bedingungen immer in geschweiften Klammern stehen müssen,
- der Code automatisch formatiert werden muss oder zumindest korrekt eingerückt,
- der Code einer automatischen und statischen Code-Analyse auf Verletzung der Kodierrichtlinien unterzogen wird und
- der Code einem Code-Review zu unterziehen ist, das nicht nur, aber auch, die Kodierrichtlinien bzw. die Ergebnisse der statischen Code-Analyse zum Gegenstand hat.
Dieser Fehler ist ja ein Standard-Fehler, den ich selbst schon unzählige Male gemacht habe – bis ich mich an die obigen Regeln gehalten habe.
Da die ersten drei Punkte automatisiert durchgeführt bzw. geprüft werden können, gibt es für mich keinen Grund, auf Kodierrichtlinien und eine Code-Analyse zu verzichten.
Werkzeuge für die Überprüfung von Kodierrichtlinien
Es gibt Kodierrichtlinien, die unabhängig von der Programmiersprache gelten, andere sind wiederum spezifisch. Wikipedia listet eine Vielzahl an Werkzeugen für die Überprüfung von Kodierrichtlinien sortiert nach Programmiersprache.
Ich nehme an es handelt sich beim Titel „Coding Guidelines des NSA“ um einen Typo – NASA ist wahrscheinlich gemeint 😉 .
Danke für die kurze Zusammenfassung der Regeln und insbesondere den Link auf „The Power of Ten – Rules for Developing Safety Critical Code“ – sehr spannend.
Sie haben absolut Recht! Danke. lieber Herr Wysmann! Es heißt jetzt NASA. Da ist die Paranoia durchgebrochen!? 😉
bei 5. der NASA Guidelines ist im Original „should average to a minimum of two assertions per function“ zu lesen
Danke für den wichtigen Hinweis! Der Text ist entsprechend überarbeitet.
Hallo,
entsprechend der Richtlinie ist der Entwicklungsprozess einer Software auch zu betrachten, ähnlich wie bei der Entwicklung eines Medizinproduktes oder IVD?
Denn gemäß dem Fall, eine bereits vorhandene Software wird modifiziert zum Betrieb in Verbindung mit einem IVD oder Medizinprodukt (Bsp. Bilderkennung und -verarbeitungssoftware), so ist die Grundlage etwas existierendes (durch Partner zur Verfügung gestellt oder gar openSource). Dann lässt sich der ursprüngliche Entwicklungsprozess selbst nicht mehr nachvollziehen. Ergo müsste man dann wieder bei null beginnen.
Oder vertu ich mich da gerade?
Sehr geehrter Herr Hampel,
ich bin nicht ganz sicher, ob ich Ihre Frage wirklich verstehe. Daher antworte ich etwas ins Blaue:
Eine Software, die ein Medizinprodukt (gemäß MDD oder IVD) oder ein Zubehör dazu ist, muss gemäß einem Entwicklungsprozess und weiteren Vorgaben entwickelt werden, wie sie die IEC 62304 beschreibt.
Sie haben durchaus die Möglichkeit, bereits bestehende Code-Stücke oder Komponenten im Sinne von SOUP mit in die Software zu integrieren. Dann benötigen Sie keine Dokumentation des Herstellers dieser SOUP. Wenn Sie vom SOUP-Hersteller sogar den Code haben, können Sie quasi nachträglich den Entwicklungsprozess mit den entsprechenden Entwicklungsstufen durchlaufen und dadurch diese Mangel „heilen“.
Viele Grüße, Christian Johner