안전 필수 프로그램 작성을 위한 NASA의 10가지 코딩 규칙

크고 복잡한 소프트웨어 프로젝트는 다양한 코딩 표준과 지침을 사용합니다. 이 지침은 소프트웨어를 작성하는 동안 따라야 하는 기본 규칙을 설정합니다. 일반적으로 다음을 결정합니다.

a) 코드를 어떻게 구성해야 하나요?
b) 어떤 언어 기능을 사용하거나 사용하지 않아야 합니까?

효과적이려면 규칙 집합이 작아야 하고 쉽게 이해하고 기억할 수 있을 정도로 구체적이어야 합니다.

NASA에서 일하는 세계 최고의 프로그래머는 안전에 중요한 코드를 개발하기 위한 일련의 지침을 따릅니다. 실제로 NASA의 제트 추진 연구소(JPL)를 비롯한 많은 기관에서 C 프로그래밍 언어로 작성된 코드에 중점을 두고 있습니다. 논리 모델 추출기, 디버거, 안정적인 컴파일러, 강력한 소스 코드 분석기 및 메트릭 도구와 같이 이 언어에 대한 광범위한 도구 지원이 있기 때문입니다.

중요한 경우, 특히 인간의 생명이 정확성과 효율성에 달려 있는 경우 이러한 규칙을 적용해야 합니다. 예를 들어 비행기, 우주선 또는 원자력 발전소를 제어하는 ​​데 사용되는 소프트웨어 프로그램입니다.

그러나 우주 기관이 기계를 작동하는 데 사용하는 표준이 무엇인지 아십니까? 아래에는 JPL 수석 과학자 Gerard J. Holzmann이 제시한 NASA의 10가지 코딩 규칙이 나열되어 있습니다. 모두 주로 보안 매개변수에 중점을 두고 있으며 다른 프로그래밍 언어에도 적용할 수 있습니다.

규칙 1번 – 간단한 제어 흐름

매우 간단한 제어 흐름 구조로 프로그램 작성 – setjmp를 사용하지 마십시오. 또는 longjmp 구성, 이동 명령문 및 직접 또는 간접 재귀 .

이유: 간단한 제어 흐름으로 인해 코드 명확성이 향상되고 검증 기능이 강화됩니다. 재귀가 없으면 순환 함수 호출 그래프가 없습니다. 따라서 경계되어야 하는 모든 실행은 실제로 경계를 유지합니다.

규칙 2 – 루프의 고정 상한

모든 루프에는 고정된 상한이 있어야 합니다. 검증 도구는 루프 반복 횟수에 대한 사전 설정 상한을 초과할 수 없음을 정적으로 증명할 수 있어야 합니다.

루프 바운드를 정적으로 증명할 수 없으면 규칙을 위반한 것으로 간주됩니다.

이유: 루프 경계가 있고 재귀가 없으면 런어웨이 코드가 방지됩니다. 그러나 이 규칙은 종료되지 않는 반복(예:프로세스 스케줄러)에는 적용되지 않습니다. 이러한 경우 역 규칙이 적용됩니다. 반복을 종료할 수 없음을 정적으로 증명할 수 있어야 합니다.

규칙 3 - 동적 메모리 할당 없음

초기화 후 동적 메모리 할당을 사용하지 마십시오.

이유: malloc과 같은 메모리 할당자 , 그리고 가비지 수집기는 성능에 예외적으로 영향을 줄 수 있는 예측할 수 없는 동작을 하는 경우가 많습니다. 또한, 다음을 포함하는 프로그래머의 실수로 인해 메모리 오류가 발생할 수도 있습니다.

<울>

물리적으로 사용 가능한 것보다 더 많은 메모리 할당 시도

메모리 확보를 잊어버림

해제된 메모리를 계속 사용

할당된 메모리의 한계 초과

모든 모듈이 미리 할당된 고정된 저장 영역 내에 있도록 하면 이러한 문제를 제거하고 메모리 사용을 더 쉽게 확인할 수 있습니다.

힙에서 메모리 할당이 없을 때 동적으로 메모리를 요청하는 한 가지 방법은 스택 메모리를 사용하는 것입니다.

규칙 4 – 대규모 기능 금지

어떤 함수도 선언당 한 줄, 명령문당 한 줄로 표준 참조 형식으로 한 장의 종이에 인쇄할 수 있는 것보다 길지 않아야 합니다. 즉, 함수의 코드는 60줄을 넘지 않아야 합니다.

이유: 지나치게 긴 함수는 종종 구조가 좋지 않다는 신호입니다. 각 기능은 이해하고 검증할 수 있는 논리적 단위여야 합니다. 컴퓨터 디스플레이의 여러 화면에 걸쳐 있는 논리 단위를 이해하는 것은 상당히 어렵습니다.

규칙 번호 5 - 낮은 주장 밀도

프로그램의 주장 밀도는 함수당 최소 2개의 주장을 평균해야 합니다. 어설션은 실제 실행에서 절대 발생해서는 안 되는 비정상적인 조건을 확인하는 데 사용됩니다. 부울 테스트로 정의해야 합니다. 주장이 실패하면 명시적인 복구 조치를 취해야 합니다.

정적 검사 도구가 어설션이 절대 실패하거나 유지될 수 없음을 증명하는 경우 규칙 위반으로 간주됩니다.

이유: 업계 코딩 노력 통계에 따르면 단위 테스트는 10~100줄의 코드당 적어도 하나의 결함을 포착합니다. 어설션 밀도에 따라 결함을 가로챌 가능성이 높아집니다.

주장의 사용은 강력한 방어 코딩 전략의 일부이기 때문에 중요합니다. 그들은 함수의 사전 및 사후 조건, 매개 변수, 함수 및 루프 불변의 반환 값을 확인하는 데 사용됩니다. 성능에 중요한 코드를 테스트한 후 어설션을 선택적으로 비활성화할 수 있습니다.

규칙 6 – 최소 범위 수준에서 데이터 개체 선언

이것은 데이터 은닉의 기본 원칙을 지원합니다. 모든 데이터 개체는 가능한 가장 작은 범위 수준에서 선언되어야 합니다.

이유: 개체가 범위에 없으면 해당 값을 참조하거나 손상시킬 수 없습니다. 이 규칙은 오류 진단을 복잡하게 할 수 있는 호환되지 않는 여러 목적으로 변수를 재사용하는 것을 금지합니다.

읽기:역대 가장 위대한 컴퓨터 프로그래머 20인

규칙 7 – 매개변수 및 반환 값 확인

void가 아닌 함수의 반환 값은 호출하는 각 함수에서 확인해야 하며, 매개변수의 유효성은 각 함수 내에서 확인해야 합니다.

가장 엄격한 형식에서 이 규칙은 printf의 반환 값도 의미합니다. 명세서 및 파일 닫기 명세서를 확인해야 합니다.

이유: 오류에 대한 응답이 성공에 대한 응답과 정당하게 다르지 않은 경우 반환 값을 명시적으로 확인해야 합니다. 이것은 일반적으로 닫기 호출의 경우입니다. 및 printf . 함수 반환 값을 명시적으로 void –로 캐스팅하는 것은 허용됩니다. 코더가 명시적으로(우연한 것이 아님) 반환 값을 무시하기로 결정했음을 나타냅니다.

규칙 8 – 전처리기의 제한적 사용

전처리기의 사용은 헤더 파일과 매크로 정의를 포함하는 것으로 제한되어야 합니다. 재귀적 매크로 호출, 토큰 붙여넣기 및 변수 인수 목록은 허용되지 않습니다.

동일한 헤더 파일의 다중 포함을 피하는 표준 상용구를 넘어서는 대규모 애플리케이션 개발 노력에서도 하나 또는 두 개 이상의 조건부 컴파일 지시문에 대한 정당성이 있어야 합니다. 이러한 각각의 사용은 도구 기반 검사기에 의해 표시되고 코드에서 정당화되어야 합니다.

이유: C 전처리기는 코드 명확성을 파괴하고 많은 텍스트 기반 검사기를 혼동시킬 수 있는 강력하고 모호한 도구입니다. 무제한 전처리기 코드에서 구문의 효과는 공식 언어 정의가 있더라도 해독하기가 매우 어려울 수 있습니다.

조건부 컴파일에 대한 주의도 마찬가지로 중요합니다. 10개의 조건부 컴파일 지시문만 있으면 1024개의 가능한 버전(2^10)의 코드가 있을 수 있으므로 필요한 테스트 노력이 증가합니다.

읽기:올해 배울 9가지 새로운 프로그래밍 언어

규칙 9 – 포인터의 제한적 사용

포인터 사용을 제한해야 합니다. 한 수준 이상의 역참조가 허용되지 않습니다. 포인터 역참조 작업은 typedef 내부에 숨겨져서는 안 됩니다. 선언 또는 매크로 정의.

함수 포인터도 허용되지 않습니다.

이유: 포인터는 전문가라도 쉽게 오용됩니다. 특히 도구 기반 정적 분석기가 프로그램의 데이터 흐름을 따르거나 분석하는 것을 어렵게 만듭니다.

함수 포인터는 또한 정적 분석기가 수행하는 검사 유형을 제한합니다. 따라서 구현에 대한 강력한 정당성이 있는 경우에만 사용해야 합니다. 함수 포인터를 사용하면 도구에서 재귀가 없음을 증명하는 것이 거의 불가능하므로 이러한 분석 기능 손실을 보충하기 위한 대체 방법을 제공해야 합니다.

읽기:코드 작성을 위한 14가지 최고의 프로그래밍 소프트웨어

규칙 10번 – 모든 코드 컴파일

모든 코드는 개발 첫날부터 컴파일되어야 합니다. 컴파일러 경고는 컴파일러의 가장 정확한 설정에서 활성화되어야 합니다. 코드는 경고 없이 이러한 설정으로 컴파일해야 합니다.

모든 코드는 최소한 하나(하나 이상)의 최신 정적 소스 코드 분석기로 매일 확인해야 하며 경고 없이 분석 프로세스를 통과해야 합니다.

이유 :시장에는 효과적인 소스 코드 분석기가 많이 있습니다. 그 중 일부는 프리웨어 도구입니다. 어떤 코더도 이 쉽게 사용할 수 있는 기술을 사용하지 않을 변명의 여지가 없습니다. 컴파일러나 정적 분석기가 혼동되면 혼동/오류를 유발하는 코드를 다시 작성하여 보다 사소하게 유효하도록 해야 합니다.

읽기:우리가 일상 생활에서 사용하는 30가지 놀라운 NASA 발명품

NASA는 이 규칙에 대해 무엇이라고 말합니까?