많은 양의 MISRA 코드를 작성해야한다는 요구 사항이 있습니다.
첫 번째 질문 : 경험을 바탕으로 임베디드 시스템에 대해 잘 작성된 코드를 전달하기 위해 추정치를에게 줄 수 있습니까? 나는 "잘 쓰여진"것이 잘못 정의되고 모호하여 원시 추정을 요구한다는 것을 이해합니다.
두 번째 질문 : 맞춤 설정이 가능하고 (즉, 특정 경고를 억제 할 수있는) 자동 빌드 환경 (즉 명령 줄 인터페이스)에서 사용되는 도구에 대한 권장 사항
이 작업에 도움이되는 다른 유용한 제안 사항입니다.
감사합니다. Ilya.임베디드 소프트웨어 용 Misra 표준
PC-Lint도 적극 권장합니다. Visual Studio로 코드를 컴파일하는 경우 Riverblade의 플러그인 'Visual Lint'를 사용하는 것이 좋습니다. Visual Studio에서 코드를 컴파일 할 수없는 경우 명령 줄에서 PC-Lint를 계속 실행하여 좋은 결과를 얻을 수 있습니다.
일부 임베디드 시스템 컴파일러는 MISRA 적합성 테스트를 컴파일러 경고로 제공합니다. Arm7/Arm9 개발을 위해 IAR 컴파일러를 사용합니다. 컴파일러 설정에서 MISRA 컴플라이언스 체크리스트를 쉽게 구성 할 수 있습니다.
MISRA에 잘 쓰여진 코드를 작성하는 데 걸릴 시간을 예측하기위한 경험 법을 제시하는 것은 어렵습니다. 많은 것은 프로그래머의 기존 코딩 습관과 처음에 MISRA 규칙을 얼마나 철저히 준수하는지에 달려 있습니다.
대략적 견적 :
PC- 린트 사용시 2 - 3 일이됩니다.
기존 코드 작성시 초기 통과 MISRA 호환 : 처음에 코드를 작성하는 데 소요 된 시간의 10-25 %.
코드 유지 MISRA 준수 : 코드 개발에 5-10 %가 추가되었습니다. 이 비용의 절반은 일을하는 'MISRA 방식'을 따르기 위해 코더의 습관을 바꾸는 것입니다. 나머지 절반은 MISRA 준수를 보장하기위한 코드 테스트 및 검사의 추가 비용입니다.
C 및 C++ 코드의 정적 분석에 PC Lint를 사용합니다. 위반 된 MISRA 규칙을 표시하도록 구성 할 수 있으며 명령 줄 인터페이스가 있습니다.
코드 만들기 Misra는 프로그래밍 습관을 잘 따르는 편이 맘에 들지 않습니다. 당신이하려고하는 코드가 이상하고 멋진 포인터 연산을 가지고 있다면, 약간의 까다로운 규칙을 찾을 수 있습니다.
나는 PC Lint에 대해 Greg가 추천 한 두 번째 줄 것입니다. 오픈 소스 Splint도 살펴볼 가치가 있습니다.하지만 컴파일러의 경고 시스템 사이에서는 여전히 80 % 만 커버 할 수 있습니다. 나머지는 아마도 손으로 코드를 검토해야 할 것입니다.
QAC이라는 상용 도구를 사용했습니다. 이 도구는 시행 할 수 있습니다. MISRA
명령 줄 인터페이스가있어서 자동화 된 빌드 환경에서 실행되도록 설정할 수 있습니다. 적용 할 규칙은 구성 할 수 있지만 일정 시간을 소비하는 사람이 있어야합니다. MISRA 집행은 매우 간단하고 충분히 효과적입니다. 나는 이것이 (FDA와 같은) 일부 기관이 코드를 평가하는 데 사용하는 도구 중 하나라는 말을 들었다. 대부분의 정적 분석 도구와 마찬가지로 처리 할 노이즈 (가양 성)가 있습니다. 마지막으로 사용했을 때 위양성을 다시 표시하는 것을 막을 수있는 좋은 방법이 없었습니다 (불만을 제기하는 코드를 변경하지 않고).
나는 주니어 엔지니어가 설치를 위해 일주일 (4-5 일) 정도 소요될 것이라고 생각합니다 (원하는대로 작동하도록 결정했다고 가정).
참고로 다른 상업용 정적 분석 도구는 MISRA 적용 가능성이 있습니다. 보고 된 바에 따르면 (영업 담당자별로) Klocwork입니다.
주니어 엔지니어는 MISRA 준수 코드를 변환하도록 지정하면 안됩니다. 내 경험에 비추어 볼 때, 그들은 도구의 경고에 따라 슬기롭게 끝날 것이며, 대부분 도구에 관계없이 잘못된 것입니다. 그들은 문제를 일으키는 것보다 더 많은 문제를 일으킬 수 있습니다. – Lundin
우리는 Misra 규칙을 개조하는 것과 비슷한 문제가있었습니다. 우리는 대규모 프로젝트에 몇 가지 코드 품질 문제가 있었고 MISRA를 사용하여 코드 품질을 개선하기로 결정했습니다.
MISRA C 규칙을 지원하는 Green Hills 컴파일러를 사용합니다. 스탠드 얼론 체커도 있습니다. 당신이하고 싶은 일에 따라 모든 규칙을 조금씩 바꾸어 버릴 수 있습니다. 우리는 한 번에 하나의 규칙을 변경하여 제한된 수의 비슷한 문제를 해결할 시간을주었습니다. 그렇지 않으면 오류의 양에 완전히 압도되었습니다.
우리의 경고는 독립 실행 형 도구가 아닌 컴파일러에 의해 생성되었으므로 검사기를 실행할 때뿐 아니라 개발할 때 오류가 표시됩니다. 우리가 개발을 계속할 때 우리는 하나의 빅뱅이 아닌 우리의 코드를 준수하게되었습니다. 이렇게하면 새 코드를 망칠 오래된 습관을 방지하여 나중에 코드를 다시 작성해야 할 필요가 없습니다.
코드가 어떻게 작동하는지 정확히 알지 못하기 때문에 이전 코드를 준수하기가 어려울 때도 있습니다. 당신이 단위 테스트를하기를 바랍니다.
다른 고고학자 (또는 수색자)의 이익을 위해 MISRA는 지침을 항상 제공하고 있으며 이는 항상 맹목적으로 따라야하는 것은 아님을 기억하는 것이 중요합니다.
나는 MISRA를 염두에두고 새로운 코드를 작성하는 것을 추천한다; 그러므로 준수를 유지하는 것이 훨씬 쉬울 것입니다.
그러나 항상 가능한 것은 아닙니다. 특히 가이드 라인에 맞게 코드를 리버스 엔지니어링하려고 할 때 그렇습니다. 이 경우에는 필수 규칙에 초점을 맞추고 조언을 보너스로 취급하는 것이 좋습니다 ... 비용 v 혜택은 여기에도 적용됩니다!
또한 위반 프로세스가 있다는 것을 명심하십시오. 규정을 준수하지만 읽을 수없는 스파게티를 고안하는 것보다 편차가있는 깨끗하고 유지 가능한 코드를 유지하는 것이 좋습니다.
이 질문은 필요한 MISRA 버전에 따라 크게 달라질 수 있습니다. 최신 2012 버전은 많은 회사의 도구 지원이 부족합니다. – Lundin