Я всегда задавался вопросом, как проект/команда/компания выбирает или может выбрать подходящий ориентир, который следует соблюдать, как MISRA 1998/2004/2012? Как следует знать и решать, какие рекомендации будут достаточными (стоимость против времени и качества) для квалификации проекта?Выбор Руководства: MISRA 1998 или MISRA 2004 или MISRA 2012?
(я знаю, что его вопрос немного тупой, но любые ответы будут оценены)
Это часто требуется от области применения. У вас будут стандарты безопасности, определяющие, что используется безопасное подмножество языка программирования. Это требование может исходить от стандартов SIL, таких как IEC 61508, автомобильный IEC 26262, аэрокосмический DO-178 и т. Д. В таких критически важных системах у вас может не быть другого выбора, кроме как использовать MISRA-C.
Но MISRA-C также становится отраслевым стандартом для всех встроенных систем, независимо от их характера. Причина очевидна: никому, независимо от области применения, не нравится плохое, некачественное программное обеспечение, полное ошибок.
Внедрение MISRA-C вместе с инструкциями по кодированию компании, правилами стиля, статическим анализом, контролем версий ... все это значительно улучшит качество конечного продукта. И это заставит программистов просвещать себя о C, становясь более профессиональным в целом.
Это, как говорится, MISRA-C не обязательно является наиболее подходящим набором правил для каждой компании. Он в основном применим к встроенным системам. Для других видов приложений нечто подобное CERT-C может быть более актуальным. Удобно использовать один из этих хорошо известных стандартов, потому что тогда вы можете автоматизировать тесты со статическими анализаторами.
Ключи здесь в том, что каждая полупрофессиональная компания, производящая программное обеспечение, нуждается в каких-то правилах кодирования, которые фокусируются на , запрещающем плохую практику. Некоторые компании склонны уделять слишком много внимания главным образом неважным деталям стиля, например, где разместить {, когда им следует сосредоточиться на вещах, которые действительно улучшают качество программного обеспечения, например «мы должны избегать написания макросов типа функции».
Правила кодирования должны быть интегрированы с подпрограммами разработки. Не имеет смысла реализовывать MISRA-C для одного проекта. Существует много работы, связанной с его запуском и запуском.
Очень важно то, что у вас есть, по крайней мере, один, желательно несколько ветеранов C с многолетним опытом, которым вы управляете правилами кодирования. Им нужно прочитать каждую грязную деталь документа MISRA и решить, какие правила имеют смысл для компании. Некоторые из правил далеки от тривиальных, чтобы понять. Не все из них имеют смысл в каждой ситуации. Если ваша команда разработчиков состоит исключительно из новичков или на опыте опытных программистов, и вы решите следовать MISRA в письме, это закончится плохо. Вам нужен хотя бы один ветеран-программист, обладающий достаточными знаниями, чтобы делать звонки о том, какие правила следует соблюдать и от которых можно отклониться.
Что касается того, какую версию MISRA-C выбрать, всегда используйте последнюю версию: 2012. Она была очищена совсем немного, и некоторые странные правила были удалены. Он также поддерживает C99, в отличие от старых.
Как и в случае с вашим комплектом компилятора или средой разработки и/или с вашими инструментами статического анализа, соответствующая версия должна быть определена на основе проекта, так как это может быть сложно изменить позже!
Если вы начинаете проект с нуля, то я бы рекомендовал MISRA C: 2012 принят - возможно, также приняв руководство новой (апрель 2016) MISRA Compliance
Новое руководство Compliance также предлагает рекомендации по как обрабатывать принятый код (т.е. предварительно существующий или импортированный код).
Существующие проекты, которые были разработаны в более ранних версиях, должны продолжать использовать эту более раннюю версию ... если нет хорошего бизнес-кейса для изменения. Изменение WILL приведет к некоторой доработке!
Код должен быть записан таким образом, чтобы он имел определенные желаемые свойства (критерии качества). Некоторые критерии качества практически всегда желательны, такие как правильность, удобочитаемость, ремонтопригодность (даже здесь есть исключения, например, если вы вводите код для запутанного конкурса c или underhanded c contest). Другие критерии качества применимы только для определенных проектов или организаций, например переносимости для 16-разрядных машин.
Хорошо сформулированное правило кодирования обычно поддерживает один или несколько критериев качества. Однако это может противоречить другим. Существует большое количество установленных правил кодирования, которые поддерживают типично желаемые критерии качества, но без значительного негативного воздействия на других. Многие из них были идентифицированы довольно давно (Kernighan and Plauger: Elements of Programming Style, 1974, и, да, у меня есть его копия :-). Порой идентифицируются дополнительные хорошие правила.
Если в очень редких случаях (например, умышленном обфускации) код должен следовать этим «установленным хорошим правилам», не имеет значения, являются ли они частью MISRA-XXXX или нет. И, если будет найдено новое хорошее правило, убедитесь, что люди начинают следовать за ним. Вы даже можете принять решение применить это новое правильное правило к уже существующему коду, но это скорее решение руководства из-за риска.
Просто не имеет смысла не следовать правильному правилу только потому, что он не является частью MISRA-XXXX. Точно так же не имеет смысла следовать плохому правилу только потому, что он является частью MISRA-XXXX. (В MISRA-C-2004 говорится, что они удалили 16 правил из MISRA-1998, потому что «у них не было смысла» - надеюсь, некоторые разработчики заметили и не применяли их. И, как упоминает Лундин, в MISRA-2012 снова некоторые «странные правила» были удалены).
Однако имейте в виду, что для почти каждого правила его бездумное приложение может в определенных ситуациях даже ухудшать критерии качества, которые он обычно поддерживает.
В дополнение к тем общепринятым правилам существуют правила, которые имеют отношение только к конкретным критериям качества для вашего кода. Что усложняет ситуацию, так это то, что в большинстве проектов для разных частей кода различные критерии качества имеют разную значимость.
За исключением вышеупомянутых «установленных хороших правил», фиксированный набор правил кодирования, следовательно, не может хорошо работать для всех частей типичного программного обеспечения. Итак, для каждой части программного обеспечения сначала определите, какие критерии качества релевантны для этой части. Затем примените те шаблоны, принципы и правила, которые действительно поддерживают эти конкретные критерии качества соответствующим образом.
Но как насчет MISRA? Правила MISRA предназначены для поддержки критериев качества, таких как правильность посредством анализируемости (например, запрет рекурсии и управления динамической памятью), переносимость (например, выделение кода сборки). То есть для частей программного обеспечения, где эти конкретные критерии качества не имеют отношения к делу, соответствующие правила MISRA не приносят никакой пользы. К сожалению, MISRA не имеет понятия архитектуры программного обеспечения, где разные части имеют разные критерии качества.
Хотя многие правила улучшились по сравнению с релизами MISRA, существует еще много правил, которые более строгие, чем необходимо (например, «no/* внутри // комментарии и наоборот» - почему?) И правила, которые пытаются избежать (маловероятные) ошибки, которые могут ввести проблемы, а не решать их (например, «повторное использование какого-либо имени, даже в разных локальных областях»). Вот мой совет для вас: если вы a) действительно хотите, чтобы ваш контролер правил обнаружил все ошибки и b) не возражайте, чтобы получить абсурдное количество предупреждений с высоким коэффициентом ложноположительного отношения, это одно правило/checker делает все это для вы: «предупреждение: обнаружена строка кода: < строка кода>».
И, наконец, MISRA разрабатывается в предположении, что C (в частности, его арифметика) слишком сложно понять. MISRA разрабатывает собственную арифметику на вершине C, полагая, что разработчики вместо этого должны изучать арифметику MISRA, а затем могут уйти без понимания C-арифметики. По-видимому, это не удалось, потому что модель MISRA-2004 («базовый тип») была заменена другой («основной тип») в MISRA-2012. Таким образом, если ваша команда хорошо понимает C и использует хороший инструмент статического анализа (или даже несколько), который способен идентифицировать проблемные сценарии с арифметикой C, подход MISRA, скорее всего, не для вас.
TL; DR: соблюдать стандартные рекомендации, применять установленные хорошие правила. Определите конкретные критерии качества для разных частей вашей архитектуры. Для каждой части примените шаблоны, принципы и правила, соответствующие этой части. Понимание правил перед их применением. Не применяйте глупые правила. Используйте хороший статический анализ кода. Убедитесь, что ваша команда понимает C.