Zehn Programmierprinzipien für großartige NASA-Programmierer

Entwickler bei der NASA ist einer der anspruchsvollsten Jobs in der Programmierwelt. Ihr Hauptaugenmerk liegt auf dem Schreiben von Code und der Entwicklung sicherer, geschäftskritischer Anwendungen.

In diesem Fall ist es wichtig, einige strenge Codierungsregeln zu befolgen. Diese Regeln decken viele Aspekte der Softwareentwicklung ab, z. B. wie Software codiert werden sollte, welche Sprachfunktionen verwendet werden sollten usw.

Obwohl es schwierig ist, sich auf einen guten Codierungsstandard zu einigen, hält sich das Jet Propulsion Laboratory (JPL) der NASA an eine Codierungsregel namens „Potenzen von Zehn: Regeln für die Entwicklung sicherer kritischer Codes“.

Da JPL seit langem die Sprache C verwendet, gilt diese Regel hauptsächlich für das Schreiben in der Programmiersprache C. Diese Regeln lassen sich aber problemlos auf andere Programmiersprachen übertragen.

Diese strengen Codierungsregeln wurden von Gerard J. Holzmann, Chefwissenschaftler am JPL, entwickelt und konzentrieren sich in erster Linie auf die Sicherheit.

Die 10 Regeln der NASA zum Schreiben von geschäftskritischem Code:

1. Beschränken Sie den gesamten Code auf extrem einfache Kontrollflussstrukturen – keine goto-Anweisungen, setjmp- oder longjmp-Strukturen, keine indirekten oder direkten rekursiven Aufrufe.

2. Alle Schleifen müssen eine feste Obergrenze haben. Es muss durch ein Erkennungstool statisch bestätigt werden, dass die Schleife die voreingestellte Iterationsobergrenze nicht erreichen kann. Kann diese Obergrenze statisch nicht nachgewiesen werden, so kann dieser Grundsatz als verletzt angesehen werden.

3. Verwenden Sie nach der Initialisierung keine dynamische Speicherzuweisung.

4. Wenn Sie sich auf das Standardformat mit einer Anweisung pro Zeile und einer Deklaration pro Zeile beziehen, sollte die Länge der Funktion nicht länger als ein Blatt Papier sein. Normalerweise bedeutet dies, dass pro Funktion nicht mehr als 60 Codezeilen erforderlich sind.

5. Die Assertionsdichte im Code beträgt durchschnittlich nur 2 Assertionen pro Funktion. Behauptungen werden verwendet, um Situationen zu erkennen, die bei der tatsächlichen Ausführung wahrscheinlich nicht auftreten. Behauptungen dürfen keine Nebenwirkungen haben und sollten als boolesche Tests definiert werden. Wenn eine Behauptung fehlschlägt, sollte eine explizite Wiederherstellungsaktion durchgeführt werden, z. B. die Rückgabe einer Fehlerbedingung an den Aufrufer der Funktion, die die Behauptung fehlgeschlagen hat. Bei statischen Tools verstößt jede Behauptung, bei der das statische Tool beweisen kann, dass sie niemals fehlschlägt oder niemals ausgelöst wird, gegen diese Regel (z. B. ist es unmöglich, diese Regel durch das Hinzufügen nutzloser „asset(true)“-Anweisungen zu erfüllen).

6. Datenobjekte müssen im kleinsten Umfang deklariert werden.

7. Der Rückgabewert einer nicht leeren Funktion muss bei jedem Aufruf der Funktion überprüft werden, und die Gültigkeit ihrer Parameter muss innerhalb jeder Funktion überprüft werden.

8. Die Verwendung von Präprozessoren beschränkt sich auf die Einbindung von Header-Dateien und einfachen Makrodefinitionen. Symbolspleißen, variable Argumentlisten (Ellipsen) und rekursive Makroaufrufe sind nicht zulässig. Alle Makros müssen zu vollständigen Syntaxeinheiten erweiterbar sein. Die Verwendung von Anweisungen zur bedingten Kompilierung ist oft unklar, aber nicht immer vermeidbar. Dies bedeutet, dass selbst in einer großen Softwareentwicklung mehr als eine oder zwei Anweisungen zur bedingten Kompilierung gute Gründe haben müssen, die über die Standardpraxis hinausgehen, die mehrfache Einbindung von Header-Dateien zu vermeiden. Jedes Mal, wenn Sie dies in Ihrem Code tun, muss es von einem werkzeugbasierten Prüfer gekennzeichnet werden, und das aus gutem Grund.

9. Die Verwendung von Zeigern sollte eingeschränkt werden. Insbesondere sollte es nicht mehr als eine Ebene der Zeiger-Dereferenzierung geben. Operationen zur Dereferenzierung von Zeigern können nicht implizit in Makrodefinitionen oder Typdeklarationen erfolgen. Außerdem sind Funktionszeiger nicht zulässig.

10. Ab dem ersten Tag der Entwicklung muss der Code so kompiliert werden, dass der Compiler die Warnoption der höchsten Ebene aktiviert. Bei dieser Einstellung muss der Code ohne Warnungen kompiliert werden. Der Code muss mindestens einmal oder mehrmals täglich mit Tools zur statischen Analyse des Quellcodes überprüft werden und ohne Warnungen bestehen.
Zu diesen Regeln sagte die NASA Folgendes:

Diese Regeln sind wie Sicherheitsgurte im Auto. Anfangs fühlen Sie sich vielleicht etwas unwohl, aber nach einer Weile wird es zur Gewohnheit und Sie können sich nicht mehr vorstellen, sie nicht zu benutzen.

Über den Autor:

Adarsh ​​​​Verma ist Mitbegründer von Fossbytes. Er ist ein angesehener Unternehmer, der stets großen Wert auf Open Source, technologische Durchbrüche und Vollständigkeit legt. Sie können ihn per E-Mail kontaktieren – [email protected]

Das obige ist der detaillierte Inhalt vonZehn Programmierprinzipien für großartige NASA-Programmierer. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!