セーフティクリティカルプログラムを作成するためのNASAの10のコーディングルール

大規模で複雑なソフトウェアプロジェクトでは、さまざまなコーディング標準とガイドラインが使用されます。これらのガイドラインは、ソフトウェアを作成する際に従わなければならない基本ルールを確立します。通常、彼らは以下を決定します：

a） コードはどのように構成する必要がありますか？
b） どの言語機能を使用する必要があるか、使用しないでください？

効果を上げるには、一連のルールを小さくし、簡単に理解して覚えられるように具体的にする必要があります。

NASAで働く世界のトッププログラマーは、セーフティクリティカルなコードを開発するための一連のガイドラインに従います。実際、NASAのジェット推進研究所（JPL）を含む多くの機関は、Cプログラミング言語で記述されたコードに焦点を当てています。これは、ロジックモデルエクストラクタ、デバッガ、安定したコンパイラ、強力なソースコードアナライザ、メトリックツールなど、この言語に対する広範なツールサポートがあるためです。

重大なケースでは、特に人間の生活がその正確さと効率に依存する可能性がある場合は、これらのルールを適用する必要があります。たとえば、飛行機、宇宙船、または原子力発電所を制御するために使用されるソフトウェアプログラム。

しかし、宇宙機関がマシンを操作するために使用する標準を知っていますか？以下に、JPLの主任科学者であるGerard J.Holzmannによって定められたNASAの10のコーディングルールを示します。これらはすべて主にセキュリティパラメータに焦点を当てており、他のプログラミング言語にも適用できます。

ルールNo.1 –単純な制御フロー

非常に単純な制御フロー構造でプログラムを作成する– setjmp を使用しないでください または longjmp コンストラクト、 goto ステートメント、および直接的または間接的な再帰 。

理由： 単純な制御フローにより、コードの明確性が向上し、検証機能が強化されます。再帰がないと、循環関数呼び出しグラフはありません。したがって、制限されるはずのすべての実行は、実際には制限されたままになります。

ルールNo.2 –ループの上限を修正

すべてのループには、固定された上限が必要です。検証ツールは、ループの反復回数の事前設定された上限を超えてはならないことを静的に証明できるはずです。

ループバウンドを静的に証明できない場合、ルールに違反していると見なされます。

理由： ループ境界が存在し、再帰が存在しないため、コードが暴走するのを防ぎます。ただし、このルールは、終了しないことを意図した反復（プロセススケジューラなど）には適用されません。このような場合、逆のルールが適用されます。反復が終了できないことを静的に証明できる必要があります。

ルールNo.3 –動的メモリ割り当てなし

初期化後に動的メモリ割り当てを使用しないでください。

理由： malloc のようなメモリアロケータ 、およびガベージコレクターは、パフォーマンスに例外的に影響を与える可能性のある予測できない動作をすることがよくあります。さらに、メモリエラーは、プログラマーのミスが原因で発生することもあります。これには、

が含まれます。

• 物理的に利用可能なメモリよりも多くのメモリを割り当てようとしています
• メモリを解放するのを忘れる
• 解放された後もメモリを使い続ける
• 割り当てられたメモリの境界を超える

すべてのモジュールを事前に割り当てられた固定のストレージ領域内に配置することで、これらの問題を解消し、メモリ使用量の確認を容易にすることができます。

ヒープからのメモリ割り当てがない場合にメモリを動的に要求する1つの方法は、スタックメモリを使用することです。

ルールNo.4 –大きな機能はありません

関数は、宣言ごとに1行、ステートメントごとに1行の、標準の参照形式で1枚の用紙に印刷できるものより長くすることはできません。つまり、関数には60行を超えるコードを含めることはできません。

理由： 過度に長い関数は、多くの場合、構造が不十分であることを示しています。各関数は、理解可能で検証可能な論理ユニットである必要があります。コンピュータディスプレイの複数の画面にまたがる論理ユニットを理解するのは非常に困難です。

ルールNo.5 –低アサーション密度

プログラムのアサーション密度は、関数ごとに最低2つのアサーションに平均化する必要があります。アサーションは、実際の実行では決して発生しない異常な状態をチェックするために使用されます。それらはブールテストとして定義する必要があります。アサーションが失敗した場合は、明示的な回復アクションを実行する必要があります。

静的チェックツールにより、アサーションが失敗したり保持されたりすることがないことが証明された場合、ルールに違反していると見なされます。

理由： 業界のコーディング作業統計によると、単体テストは10〜100行のコードごとに少なくとも1つの欠陥をキャプチャします。欠陥を傍受する可能性は、アサーション密度とともに増加します。

アサーションは強力な防御コーディング戦略の一部であるため、アサーションの使用も重要です。これらは、関数の事前条件と事後条件、パラメーター、および関数とループ不変条件の戻り値を検証するために使用されます。パフォーマンスが重要なコードをテストした後、アサーションを選択的に無効にすることができます。

ルールNo.6 –最小レベルのスコープでデータオブジェクトを宣言する

これは、データ隠蔽の基本原則をサポートしています。すべてのデータオブジェクトは、可能な限り最小のスコープレベルで宣言する必要があります。

理由： オブジェクトがスコープ内にない場合、その値を参照したり破損したりすることはできません。このルールは、障害診断を複雑にする可能性のある、互換性のない複数の目的で変数を再利用することを推奨しません。

読む：史上最高のコンピュータープログラマー20人

ルールNo.7 –パラメータと戻り値の確認

非void関数の戻り値は、呼び出し元の各関数でチェックする必要があり、パラメーターの有効性は、各関数内でチェックする必要があります。

最も厳密な形式では、このルールは printf の戻り値も意味します。 ステートメントとファイル閉じる ステートメントを確認する必要があります。

理由： エラーへの応答が成功への応答と当然変わらない場合は、戻り値を明示的にチェックする必要があります。これは通常、 close の呼び出しの場合です。 および printf 。関数の戻り値を void – に明示的にキャストすることは許容されます コーダーが明示的に（偶然ではなく）戻り値を無視することを決定したことを示します。

ルールNo.8 –プリプロセッサの限定使用

プリプロセッサの使用は、ヘッダーファイルとマクロ定義のインクルードに限定する必要があります。再帰的なマクロ呼び出し、トークンの貼り付け、および可変引数リストは許可されていません。

同じヘッダーファイルが複数含まれることを回避する標準の定型文を超えて、大規模なアプリケーション開発の取り組みにおいても、1つまたは2つ以上の条件付きコンパイルディレクティブを正当化する必要があります。そのような使用はそれぞれ、ツールベースのチェッカーによってフラグが付けられ、コードで正当化される必要があります。

理由： Cプリプロセッサは、コードの明確さを損ない、多くのテキストベースのチェッカーを混乱させる可能性のある強力であいまいなツールです。無制限のプリプロセッサコードでの構成の影響は、正式な言語定義が手元にある場合でも、解読するのが非常に難しい可能性があります。

条件付きコンパイルに対する注意も同様に重要です。条件付きコンパイルディレクティブが10個しかない場合、コードのバージョンは1024（2 ^ 10）になる可能性があり、必要なテスト作業が増える可能性があります。

読む：今年学ぶべき9つの新しいプログラミング言語

ルールNo.9 –ポインターの使用制限

ポインタの使用を制限する必要があります。間接参照のレベルは1つだけです。ポインタの逆参照操作は、 typedef 内に隠さないでください。 宣言またはマクロ定義。

関数ポインタも許可されていません。

理由： 専門家であっても、ポインタは簡単に誤用されます。特にツールベースの静的アナライザーでは、プログラム内のデータの流れを追跡または分析することが困難になります。

関数ポインターは、静的アナライザーによって実行されるチェックのタイプも制限します。したがって、それらの実装に強い正当性がある場合にのみ使用する必要があります。関数ポインタを使用すると、ツールが再帰がないことを証明することがほとんど不可能になるため、この分析機能の損失を補うための代替方法を提供する必要があります。

読む：コードを書くための14の最高のプログラミングソフトウェア

ルールNo.10 –すべてのコードをコンパイルする

すべてのコードは、開発の初日からコンパイルする必要があります。コンパイラの警告は、コンパイラの最も適切な設定で有効にする必要があります。コードは、警告なしにこれらの設定でコンパイルする必要があります。

すべてのコードは、少なくとも1つ（できれば複数）の最先端の静的ソースコードアナライザーで毎日チェックする必要があり、警告なしで分析プロセスに合格する必要があります。

理由 ：市場には効果的なソースコードアナライザーがたくさんあります。それらのいくつかはフリーウェアツールです。このすぐに利用できるテクノロジーを利用しないコーダーの言い訳は絶対にありません。コンパイラーまたは静的アナライザーが混乱した場合は、混乱/エラーの原因となるコードを書き直して、より簡単に有効になるようにする必要があります。

読む：私たちが日常生活で使用する30の驚くべきNASAの発明

NASAはこれらの規則について何と言っていますか？