NASA's 10 codeerregels voor het schrijven van veiligheidskritieke programma's

Grote en complexe softwareprojecten maken gebruik van verschillende coderingsstandaarden en richtlijnen. Deze richtlijnen leggen de basisregels vast die moeten worden gevolgd bij het schrijven van software. Meestal bepalen ze:

a) Hoe moet de code worden gestructureerd?
b) Welke taalfunctie moet wel of niet worden gebruikt?

Om effectief te zijn, moet de set regels klein zijn en specifiek genoeg zijn om gemakkelijk te begrijpen en te onthouden.

'S Werelds beste programmeurs die bij NASA werken, volgen een reeks richtlijnen voor het ontwikkelen van veiligheidskritieke code. Veel bureaus, waaronder NASA's Jet Propulsion Laboratory (JPL), richten zich zelfs op code die is geschreven in de programmeertaal C. Dit komt omdat er uitgebreide toolondersteuning is voor deze taal, zoals logische modelextractors, debuggers, stabiele compiler, krachtige broncode-analysatoren en metrische tools.

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

Maar weet u welke normen ruimtevaartorganisaties gebruiken om hun machines te bedienen? Hieronder hebben we de 10 coderingsregels van NASA vermeld die zijn opgesteld door JPL-hoofdwetenschapper Gerard J. Holzmann. Ze zijn allemaal voornamelijk gericht op beveiligingsparameters en u kunt ze ook toepassen op andere programmeertalen.

Regel nr. 1 – Eenvoudige controlestroom

Schrijf programma's met zeer eenvoudige besturingsstroomconstructies - Gebruik geen setjmp of longjmp constructies, ga naar verklaringen en directe of indirecte recursie .

Reden: Eenvoudige controlestroom resulteert in verbeterde codeduidelijkheid en sterkere mogelijkheden voor verificatie. Zonder recursie zal er geen cyclische functieaanroepgrafiek zijn. Dus alle uitvoeringen die begrensd zouden moeten zijn, blijven feitelijk begrensd.

Regel nr. 2 – Vaste bovengrens voor lussen

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

De regel wordt als geschonden beschouwd als de lus-gebonden niet statisch kan worden bewezen.

Reden:  De aanwezigheid van lusgrenzen en de afwezigheid van recursie voorkomen op hol geslagen code. De regel is echter niet van toepassing op iteraties die bedoeld zijn om niet-beëindigend te zijn (bijvoorbeeld procesplanner). In dergelijke gevallen wordt de omgekeerde regel toegepast:het moet statisch aantoonbaar zijn dat de iteratie niet kan worden beëindigd.

Regel nr. 3 – Geen dynamische geheugentoewijzing

Gebruik geen dynamische geheugentoewijzing na initialisatie.

Reden: Geheugentoewijzers zoals malloc , en vuilnisophalers hebben vaak onvoorspelbaar gedrag dat de prestaties uitzonderlijk kan beïnvloeden. Bovendien kunnen geheugenfouten optreden als gevolg van een programmeerfout, waaronder

• Poging om meer geheugen toe te wijzen dan fysiek beschikbaar is
• Vergeten geheugen vrij te maken
• Het geheugen blijven gebruiken nadat het was vrijgemaakt
• Overschrijding van de grenzen van toegewezen geheugen

Door alle modules te dwingen binnen een vast, vooraf toegewezen opslaggebied te leven, kunnen deze problemen worden verholpen en het geheugengebruik gemakkelijker worden gecontroleerd.

Een manier om dynamisch geheugen te claimen als er geen geheugentoewijzing van de heap is, is door stackgeheugen te gebruiken.

Regel nr. 4 – Geen grote functies

Geen enkele functie mag langer zijn dan wat zou kunnen worden afgedrukt op een enkel vel papier in een standaard referentieformaat met één regel per aangifte en één regel per verklaring. Dit betekent dat een functie niet meer dan 60 regels code mag hebben.

Reden: Te lange functies zijn vaak een teken van een slechte structuur. Elke functie moet een logische eenheid zijn die zowel begrijpelijk als verifieerbaar is. Het is heel wat moeilijker om een ​​logische eenheid te begrijpen die meerdere schermen op een computerscherm beslaat.

Regel nr. 5 – Lage assertiviteitsdichtheid

De beweringdichtheid van het programma moet gemiddeld minimaal twee beweringen per functie bedragen. Beweringen worden gebruikt om te controleren op abnormale omstandigheden die nooit zouden mogen voorkomen bij executies in het echte leven. Ze moeten worden gedefinieerd als Booleaanse tests. Wanneer een bewering faalt, moet een expliciete herstelactie worden ondernomen.

Als een statische controletool aantoont dat een bewering nooit kan mislukken of nooit stand kan houden, wordt de regel als overtreden beschouwd.

Reden: Volgens de coderingsinspanningsstatistieken van de industrie wordt bij eenheidstests ten minste één defect per 10 tot 100 regels code gedetecteerd. De kans op het onderscheppen van defecten neemt toe met de assertiviteitsdichtheid.

Het gebruik van assertiviteit is ook belangrijk omdat ze deel uitmaken van een sterke defensieve codeerstrategie. Ze worden gebruikt om pre- en postvoorwaarden van een functie, parameter en retourwaarde van een functie en lus-invarianten te verifiëren. Beweringen kunnen selectief worden uitgeschakeld na het testen van de prestatiekritieke code.

Regel nr. 6 – Declareer gegevensobjecten op het kleinste bereik

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

Reden: Als een object niet binnen het bereik valt, kan er niet naar de waarde worden verwezen of kan deze niet worden beschadigd. Deze regel ontmoedigt het hergebruik van variabelen voor meerdere, incompatibele doeleinden die de foutdiagnose kunnen bemoeilijken.

Lees: 20 beste computerprogrammeurs aller tijden

Regel nr. 7 – Controleer parameters en retourwaarde

De geretourneerde waarde(n) van niet-ongeldige functies moeten worden gecontroleerd door elke aanroepende functie en de geldigheid van parameters moet binnen elke functie worden gecontroleerd.

In zijn meest strikte vorm betekent deze regel zelfs de retourwaarde van printf verklaringen en bestand close verklaringen moeten worden gecontroleerd.

Reden: Als het antwoord op een fout terecht niet verschilt van het antwoord op succes, moet men expliciet een retourwaarde controleren. Dit is meestal het geval bij oproepen om af te sluiten en printf . Het is acceptabel om de functieretourwaarde expliciet te casten naar void –  wat aangeeft dat de codeur expliciet (niet per ongeluk) besluit om een ​​retourwaarde te negeren.

Regel nr. 8 – Beperkt gebruik van preprocessor

Het gebruik van de preprocessor moet worden beperkt tot het opnemen van headerbestanden en macrodefinities. Recursieve macro-aanroepen, het plakken van tokens en lijsten met variabele argumenten zijn niet toegestaan.

Er zou een rechtvaardiging moeten zijn voor meer dan een of twee voorwaardelijke compilatierichtlijnen, zelfs bij grote inspanningen voor applicatieontwikkeling, buiten de standaard boilerplate, die meerdere opname van hetzelfde headerbestand vermijdt. Elk dergelijk gebruik moet worden gemarkeerd door een tool-gebaseerde checker en verantwoord in de code.

Reden: De C-preprocessor is een krachtig en dubbelzinnig hulpmiddel dat de duidelijkheid van de code kan vernietigen en veel op tekst gebaseerde checkers kan verwarren. Het effect van constructies in onbegrensde preprocessorcode kan uitzonderlijk moeilijk te ontcijferen zijn, zelfs met een formele taaldefinitie in de hand.

De waarschuwing tegen voorwaardelijke compilatie is net zo belangrijk:met slechts 10 voorwaardelijke compilatierichtlijnen zouden er 1024 mogelijke versies (2^10) van de code kunnen zijn, wat de vereiste testinspanning zou vergroten.

Lezen:9 nieuwe programmeertalen om dit jaar te leren

Regel nr. 9 – Beperkt gebruik van aanwijzers

Het gebruik van pointers moet worden beperkt. Er is niet meer dan één niveau van dereferentie toegestaan. Aanwijzer-dereferentiebewerkingen mogen niet worden verborgen in typedef verklaring of macrodefinities.

Functieaanwijzers zijn ook niet toegestaan.

Reden: Aanwijzers worden gemakkelijk misbruikt, zelfs door experts. Ze maken het moeilijk om de gegevensstroom in een programma te volgen of te analyseren, vooral door op tools gebaseerde statische analysers.

Functieaanwijzers beperken ook het type controles dat wordt uitgevoerd door statische analysers. Ze mogen dus alleen worden gebruikt als er een sterke rechtvaardiging is voor de uitvoering ervan. Als functieaanwijzers worden gebruikt, wordt het bijna onmogelijk voor een tool om de afwezigheid van recursie te bewijzen, dus moeten alternatieve methoden worden geboden om dit verlies aan analytische mogelijkheden te compenseren.

Lezen:14 beste programmeersoftware voor het schrijven van code

Regel nr. 10 – Stel alle code samen

Alle code moet vanaf de eerste dag van ontwikkeling worden gecompileerd. De compilerwaarschuwing moet zijn ingeschakeld op de meest nauwkeurige instelling van de compiler. De code moet zonder enige waarschuwing compileren met deze instellingen.

Alle code moet dagelijks worden gecontroleerd met ten minste één (bij voorkeur meer dan één) ultramoderne statische broncode-analysator en moet het analyseproces zonder waarschuwing doorstaan.

Reden :Er zijn tal van effectieve broncode-analysatoren op de markt; een paar van hen zijn freeware tools. Er is absoluut geen excuus voor een codeur om geen gebruik te maken van deze gemakkelijk beschikbare technologie. Als de compiler of statische analysator in de war raakt, moet de code die de verwarring/fout veroorzaakt, worden herschreven zodat deze meer triviaal geldig wordt.

Lees:30 geweldige NASA-uitvindingen die we in ons dagelijks leven gebruiken

Wat zegt NASA over deze regels?