Programmierfehlern vorbeugen
14.11.2017, 11:02 Uhr
10 Regeln der NASA für sicheren Code
Wenn Entwickler der NASA einen Fehler machen, kann das tödlich sein. Diese 10 Regeln sollen für fehlerfreien Code sorgen.
(Quelle: Quelle: NASA.gov)
Hat der von der NASA verfasste Code Fehler, kann das die komplette Mission gefährden. Sind Menschen an Bord, vielleicht sogar auf einer zweijährigen Reise zum Mars, sollten sie sich auf fehlerfreien Code verlassen können. Bei der NASA sollen die folgenden zehn Regeln für sicheren Code sorgen:
- Der Code sollte auf sehr einfache Konstrukte beschränkt werden. Verboten sind Goto-Statements, setjmp- oder longjmp-Konstrukte sowie direkte oder indirekte Rekursion.
- Alle Schleifen müssen eine fixe Obergrenze haben. Es muss einfach nachprüfbar sein, dass die gesetzte Obergrenze nicht überschritten werden kann. Kann die Obergrenze für die Schleifendurchläufe nicht statisch nachgeprüft werden, gilt diese Regel als verletzt.
- Nach der Intitialisierung sollte keine dynamische Speicher-Allokaiton mehr verwendet werden.
- Keine Funktion sollte so lang sein, dass sie nicht mehr auf einem DIN A4 Blatt ausgedruckt werden kann -- in Standardschrift, mit einer Zeile pro Statement. Typischerweise sind also nicht mehr als 60 Zeilen Code pro Funktion erlaubt.
- Die Assertion Density des Codes sollte auf ein Minimum von zwei Assertions pro Funktion reduziert werden. Assertions werden benutzt, um auf unnormale Bedingungen zu prüfen, die während der Ausführung niemals auftreten sollten. Assertions müssen stets frei von Seiteneffekten sein und sollten als Boolsche Tests mit einer expliziten Recovery-Aktion für den Fall definiert werden, dass der Test fehlschlägt. Die Recovery-Aktion kann zum Beispiel darin bestehen, einen Fehler an die aufrufende Funktion zu melden. Auch hier muss sich durch ein statisches Tool nachweisen lassen, dass die Assertion nicht komplett fehlschlagen oder durch hinzufügen von Statements wie assert(true) umgangen werden kann.
- Datenobjekte müssen im geringstmöglichen Level of Scope definiert werden.
- Die Rückgabewerte von Funktionen (non-void) müssen von jeder aufrufenden Funktion geprüft werden. Zudem ist die Validität der Parameter innerhalb jeder Funktion zu prüfen.
- Die Nutzung des Präprozessors muss beschränkt werden auf das Einbinden von Header-Files und simpler Makrodefinitionen. Recursive Makroaufrufe, variable Argumentlisten sowie das einfügen von Tokens ist nicht erlaubt.
- Der Einsatz von Zeigern sollte begrenzt sein. Lediglich eine Ebene ist für das Auflösen von Bezügen (dereferencing) erlaubt. Operationen zum Auflösen von Zeiger-Referenzen dürfen nicht in Makrodefinitionen oder in typedef-Deklarationen versteckt werden.
- Vom ersten Tag der Entwicklung an ist der Compiler so einzustellen, dass alle Compiler-Warnungen angezeigt werden und zwar im pedantischsten alle verfügbaren Compiler-Modi. Das gilt für den kompletten Code. Täglich muss der komplette Code mit mindestens einem, besser aber mehreren aktuellen, statischen Code-Analyseprogrammen geprüft werden und sollte diese Tests ohne jede Warnung durchlaufen.
Die Nasa sagt zu diesen Regeln: "Die Regeln sind wie ein Sicherheitsgurt im Auto: Anfangs sind sie vielleicht etwas lästig. Aber nach einer Weile werden sie zur zweiten Natur und sie nicht einzuhalten wird unvorstellbar."
Dies ist eine Überstetzung. Das Original finden Sie unter https://fossbytes.com/nasa-coding-programming-rules-critical/
