Zehn Anleitungen, um ein Top-Programmierer zu werden, der Ihnen beim Schreiben von Programmiercode wie der NASA hilft!

Einführung

Zitat: Wissen Sie, wie die besten Programmierer der NASA geschäftskritischen Code schreiben? Um sicherzustellen, dass der Code klarer, sicherer und leichter verständlich ist, hat das Jet Propulsion Laboratory der NASA zehn Codierungsregeln entwickelt.

Der Entwicklerjob bei der NASA ist einer der anspruchsvollsten in der Programmierwelt. Ihr Hauptaugenmerk liegt auf dem Schreiben von Code und der Entwicklung sicherer, geschäftskritischer Anwendungen. Aus diesem Grund ist die Einhaltung strenger Kodierungsregeln von entscheidender Bedeutung. Diese Regeln decken viele Aspekte der Softwareentwicklung ab, einschließlich Codierungsstil, Verwendung von Sprachfunktionen usw. Obwohl es schwierig ist, sich auf einen geeigneten Codierungsstandard zu einigen, folgt das Jet Propulsion Laboratory (JPL) der NASA einer Reihe von Codierungsregeln mit der Bezeichnung „Powers of Ten: Rules for Developing Secure Critical Code“.

Diese Regeln sind in erster Linie für in C geschriebene Programme gedacht, da JPL seit langem C verwendet. Allerdings lassen sich diese Regeln auch problemlos auf andere Programmiersprachen übertragen. Diese Codierungsregeln wurden von Gerard J. Holzmann, dem Chefwissenschaftler des JPL, hauptsächlich zur Gewährleistung der Sicherheit entwickelt.

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 Dichte der Behauptungen im Code beträgt durchschnittlich nur 2 Behauptungen 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 kleinstmöglichen Umfang deklariert werden.
7. Der Rückgabewert einer nicht leeren Funktion muss bei jedem Funktionsaufruf ü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. Das 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 übliche Praxis 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 sagt 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 Anleitungen, um ein Top-Programmierer zu werden, der Ihnen beim Schreiben von Programmiercode wie der NASA hilft!. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!