NASA's 10 Essentiële Codeerregels Voor Het Ontwikkelen Van Veiligheids-kritische Software

Grote en complexe softwareprojecten gebruiken diverse coderingsstandaarden en richtlijnen. Deze richtlijnen leggen de basisregels vast die gevolgd moeten worden tijdens het schrijven van software. Meestal bepalen ze:

a) Hoe de code gestructureerd moet zijn?
b) Welke taalfeatures wel of niet gebruikt mogen worden?

Om effectief te zijn, moet de set regels klein zijn en specifiek genoeg dat het gemakkelijk begrepen en onthouden kan worden.

De werelds top programmeurs die bij NASA werken, volgen een set richtlijnen voor het ontwikkelen van veiligheids-kritische code. Feitelijk richten veel instanties, inclusief NASA's Jet Propulsion Laboratory (JPL), zich op code geschreven in de C programmeertaal. Dit is omdat er uitgebreide tool-ondersteuning is voor deze taal, zoals logica modelextractors, debuggers, stabiele compiler, sterke broncode-analyzers en metrics tools.

In kritische gevallen wordt het noodzakelijk om deze regels toe te passen, vooral waar menselijk leven kan afhangen van de correctheid en efficiëntie ervan. Bijvoorbeeld, softwareprogramma's die vliegtuigen, ruimtevaartuigen of kerncentrales besturen.

Maar weet je welke standaarden ruimtevaartorganisaties gebruiken om hun machines te bedienen? Hieronder hebben we NASA's 10 coderingsregels opgesomd, opgesteld door JPL-leadwetenschapper Gerard J. Holzmann. Ze richten zich allemaal primair op beveiligingsparameters, en je kunt ze op andere programmeertalen toepassen.

Regel Nr. 1 – Eenvoudige Controlestroom

Schrijf programma's met zeer eenvoudige controlestroom-constructies – Gebruik geen setjmp of longjmp constructies, goto statements, en directe of indirecte recursie.

Reden: Eenvoudige controlestroom resulteert in verbeterde codehelderheid en sterkere verificatiecapaciteiten. Zonder recursie zal er geen cyclische functie-aanroepgraaf zijn. Dus, alle uitvoeringen die gebonden zouden moeten zijn, blijven daadwerkelijk gebonden.

Regel Nr. 2 – Vaste Bovengrens Voor Lussen

Alle lussen moeten een vaste bovengrens hebben. Het moet mogelijk zijn voor een verificatie-tool om statisch te bewijzen dat een vooraf ingestelde bovengrens op het aantal iteraties van een lus niet overschreden kan worden.

De regel wordt geschonden als de lusgrens niet statisch bewezen kan worden.

Reden: De aanwezigheid van lusgrenzen en het ontbreken van recursie voorkomen weglopende code. Echter, de regel geldt niet voor iteraties die bedoeld zijn om niet-te beëindigen (bijvoorbeeld proces-scheduler). In dergelijke gevallen wordt de omgekeerde regel toegepast – Het moet statisch bewezen kunnen worden dat de iteratie niet kan beëindigen.

Regel Nr. 3 – Geen Dynamische Geheugentoewijzing

Gebruik geen dynamische geheugentoewijzing na initialisatie.

Reden: Geheugentoewijzers zoals malloc, en garbage collectors hebben vaak onvoorspelbaar gedrag dat uitzonderlijk de prestaties kan beïnvloeden. Bovendien kunnen geheugenfouten ook optreden door een programmeerfout, wat omvat:

• Poging om meer geheugen toe te wijzen dan fysiek beschikbaar
• Vergeten geheugen vrij te geven
• Doorgaan met het gebruiken van geheugen na het vrijgeven
• Overschrijden van grenzen op toegewezen geheugen

Alle modules dwingen om te leven binnen een vaste, vooraf toegewezen opslagruimte kan deze problemen elimineren en het gemakkelijker maken om geheugengebruik te verifiëren.

Eén manier om dynamisch geheugen te claimen in afwezigheid van geheugentoewijzing van de heap is om stack-geheugen te gebruiken.

Regel Nr. 4 – Geen Grote Functies

Geen functie mag langer zijn dan wat op een enkel vel papier geprint kan worden in een standaard referentieformaat met één regel per declaratie en één regel per statement. Dit betekent dat een functie niet meer dan 60 regels code zou mogen hebben.

Reden: Excessief lange functies zijn vaak een teken van slechte structuur. Elke functie zou een logische eenheid moeten zijn die begrijpelijk en verifieerbaar is. Het is tamelijk moeilijk om een logische eenheid te begrijpen die meerdere schermen op een computerdisplay beslaat.

Regel Nr. 5 – Lage Assertie-dichtheid

De assertiedichtheid van het programma moet gemiddeld minimaal twee asserties per functie bedragen. Asserties worden gebruikt om afwijkende condities te controleren die nooit in echte uitvoeringen mogen gebeuren. Ze moeten gedefinieerd worden als Booleaanse tests. Wanneer een assertie faalt, moet een expliciete herstelactie ondernomen worden.

Als een statische controle-tool bewijst dat een assertie nooit kan falen of nooit kan gelden, wordt de regel als geschonden beschouwd.

Reden: Volgens industriële coderingsinspanningsstatistieken vangen unit tests ten minste één defect per 10 tot 100 regels code. De kans op het onderscheppen van defecten neemt toe met assertiedichtheid.

Het gebruik van asserties is ook belangrijk omdat ze onderdeel zijn van een sterke defensieve coderingsstrategie. Ze worden gebruikt om pre- en postcondities van een functie, parameter en retourwaarde van een functie en lus-invarianten te verifiëren. Asserties kunnen selectief uitgeschakeld worden na het testen van prestatie-kritische code.

Regel Nr. 6 – Data-objecten Declareren Op Kleinste Mogelijke Scope

Deze ondersteunt het basisprincipe van data hiding. Alle data-objecten moeten gedeclareerd worden op het kleinst mogelijke niveau van scope.

Reden: Als een object niet in scope is, kan de waarde ervan niet gerefereerd of gecorrumpeerd worden. Deze rule ontmoedigt het hergebruik van variabelen voor meerdere, incompatibele doeleinden die foutdiagnose kunnen compliceren.

Regel Nr. 7 – Parameters En Retourwaarde Controleren

De retourwaarde(s) van non-void functies moeten gecontroleerd worden door elke aanroepende functie, en de geldigheid van parameters moet gecontroleerd worden binnen elke functie.

In zijn strengste vorm betekent deze regel dat zelfs de retourwaarde van printf statements en bestand sluit statements gecontroleerd moet worden.

Reden: Als de reactie op een fout met recht geen verschil heeft met de reactie op succes, moet men expliciet een retourwaarde controleren. Dit is meestal het geval met aanroepen naar sluit en printf. Het is acceptabel om de functie-retourwaarde expliciet te casten naar void – wat aangeeft dat de coder expliciet (niet per ongeluk) besluit een retourwaarde te negeren.

Regel Nr. 8 – Beperkt Gebruik Van Preprocessor

Het gebruik van de preprocessor moet beperkt worden tot de inclusie van header-bestanden en macro-definities. Recursieve macro-aanroepen, token-pasting, en variabele argumentenlijsten zijn niet toegestaan.

Er moet justificatie zijn voor meer dan één of twee conditionele compilatierichtlijnen zelfs in grote applicatie-ontwikkelingsinspanningen, buiten de standaard boilerplate, die meervoudige inclusie van hetzelfde headerbestand voorkomt. Elk dergelijk gebruik moet gevlagd worden door een tool-gebaseerde checker en gerechtvaardigd in de code.

Reden: De C preprocessor is een krachtige en ambiguë tool die de codehelderheid kan vernietigen en veel tekst-gebaseerde checkers in de war kan brengen. Het effect van constructies in onbegrensde preprocessor-code kan uitzonderlijk moeilijk zijn om te ontrafelen, zelfs met een formele taaldefinitie in hand.