# The Power of 10: NASAs Regeln für sauberen Code - (27.03.2025) Immer mehr Firmen legen Wert darauf, dass ihr Code sauber umgesetzt wird. Anders als bei den meisten Firmen jedoch, sind die Konsequenzen von schlechtem Code bei NASA sehr viel grösser. Um dieses Risiko zu minimieren, hat Gerald J. Holzmann[^1] im Namen von NASA 10 Regeln entwickelt, die für sicheren und entsprechend sauberen Code eingehalten werden müssen. In ihrer ursprünglichen Form wurden die Regeln für C und speziell für Embedded Development geschrieben. Da dies für uns Web Entwickler jedoch nicht von grosser Relevanz ist, wollen in diesem Beitrag versuchen, Parallelen zwischen den Power of 10 und Clean Code in C# zu ziehen. ## The Power of 10 Bevor wir die Regeln für uns interpretieren, wollen wir trotzdem die originale Ausführung[^2] kurz überfliegen (Deutsche Übersetzung von mir): 1. Begrenze jeglichen Code auf sehr einfache Kontroll-Fluss Konstrukte - In anderen Worten, verwende kein `goto`, Rekursion oder ähnliches. 2. Gib jeder Schleife eine feste obere Grenze - Es muss für ein Werkzeug statisch möglich sein, zu prüfen ob eine Schleife die vorgegebene Anzahl an Wiederholungen nicht überschreiten kann. 3. Benutze keine dynamische Speicher-Allokation nach der Initialisierung - Speicher-Allokatoren und Garbage Collection können unvorhersehbares Verhalten aufweisen, was die Performance beeinflussen kann. 4. Keine Funktion sollte länger sein, als was auf einem Blatt Papier gedruckt werden kann (ca. 60 Zeilen) - Sollte selbsterklärend sein. 5. Es sollten im Durchschnitt mindestens zwei Zusicherungen (*Assertions*) pro Funktion ausgeführt werden - Mit Zusicherungen kann der Zustand des Programms geprüft werden und so die Stabilität kontrolliert werden. 6. Begrenze den Umfang von Daten auf die kleinste mögliche Grösse - Daten, die nicht relevant sind, sollten auch nicht vorhanden sein. 7. Überprüfe den Rückgabewert von allen *Non-Void* Funktionen, oder ändere es auf *void* um zu signalisieren, dass der Wert irrelevant ist - Alle relevanten Rückgabewerte müssen überprüft werden oder es muss klar sein, dass sie irrelevant sind. 8. Begrenze die Nutzung von Präprozessoren auf den Einschluss von Header Files und einfache Macro-Definitionen - Mit dem Präprozessor wird der Code unleserlich, sollte also nur sparsam eingesetzt werden. 9. Die Nutzung von Pointers muss beschränkt sein - Pointers werden schnell falsch umgesetzt. auch von erfahrenen Entwicklern. 10. Jeglicher Code muss mit allen Warnungen aktiv kompiliert werden und alle Warnungen müssen vor der Veröffentlichung behoben werden - Mit den Warnungen des Compilers können viele kleine Unschönheiten erkannt werden. Da diese Warnung ein Risiko von Instabilität repräsentieren, sollten alle behoben werden. Die Regeln sind eigentlich sehr grundlegend. Es gibt jedoch einige Regeln, die bei der Verwendung von anderen Sprachen nicht von gleicher Interesse sind. Wir wollen uns also die Punkte ansehen, die auch für die Entwicklung mit C# beachtet werden sollten: ## Regeln für C\# ### Einfachheit und Lesbarkeit Die erste Regel besagt, dass komplexe *Flow Constructs* vermieden werden sollten. Auch in C# ist das ein wichtiger Punkt zu beachten. Beispielsweise sollte LINQ genutzt werden um Daten zu manipulieren anstelle von komplexen Schleifen. In dem wir unseren Programmfluss möglichst einfach halten wird der Code einfacher zu erweitern und verwalten. ### Vorhersehbare Ressourcen-Nutzung Die dritte Regel behandelt das Vermeiden von dynamischer Speicherallokation. Während die Speicherallokation in der C# Web-Entwicklung meistens nicht von grosser Interesse ist, gibt es trotzdem Punkte zu beachten, um Speicher effizienter zu nutzen. So sollte bei grossen Datenmengen beispielsweise Pagination genutzt werden um die Speichernutzung zu begrenzen. ### Modularer und verwaltbarer Code Die vierte Regel besagt, dass Funktionen auf die Grösse eines Blatt Papiers beschränkt werden sollten. Während die Regel mit dem Blatt in den meisten Projekten nicht so strikt umgesetzt werden würde, ist es nichts desto trotz eine gute Praktik, seine Funktionen möglichst klein zu halten. ### Kontrolle des Umfangs Die sechste Regel empfiehlt einen begrenzten Umfang von Daten. Auch in C# ist das von grosser Interesse. In der Praxis sollten also die *Access Modifiers* immer gut durchdacht werden und private Methoden eingesetzt werden. ### *Code Quality Assurance* Die letzte Regel empfiehlt, dass alle Compiler-Warnungen adressiert werden müssen. Diese Regel kann eins zu eins auf C# übertragen werden. Dazu kann die Code-Qualität sogar noch gesteigert werden, wenn statische Scanner wie SonarQube genutzt werden. Auch ausführliche Abdeckung von Code mit Unit Tests kann die Qualität von Code steigern. ## Fazit Die Power of 10 können sehr hilfreich, wenn Code entwickelt wird, bei dem die Sicherheit eine Priorität ist. In der C# Web-Entwicklung wird dieses Kriterium anders interpretiert, die Regeln können also nicht direkt übertragen werden. Es gibt aber immer noch Punkte, welche in beiden Gebieten relevant sind. In diesem Beitrag haben wir uns einige dieser angesehen. Auch wenn wir einige Regeln definieren konnten, empfiehlt es sich eine Praktik zu wählen, die relevanter für C# ist (Ein bekanntes Beispiel wäre *Clean Code*). [^1]: vgl. The Power of 10, in: Wikipedia, 27.03.2025, https://en.wikipedia.org/wiki/The_Power_of_10%3A_Rules_for_Developing_Safety-Critical_Code [^2]: vgl. The Power of 10: Rules for developing Safety-Critical Code, 27.03.2025, https://web.eecs.umich.edu/~imarkov/10rules.pdf