Мне всегда было интересно, как проект/команда/компания выбирает или получает право выбирать конкретное руководство, которому нужно следовать, например, MISRA 1998/2004/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, в отличие от более старых.
Код должен быть написан так, чтобы он обладал определенными желаемыми свойствами (критериями качества). Практически всегда желательны некоторые критерии качества, такие как правильность, удобочитаемость, ремонтопригодность (даже здесь есть исключения, например, если вы пишете код для запутанного конкурса c или закулисного конкурса c). Другие критерии качества актуальны только для определенных проектов или организаций, например переносимость на 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 разработана в предположении, что язык C (в частности, его арифметика) слишком сложен для понимания. MISRA разрабатывает свою собственную арифметику поверх C, полагая, что разработчики вместо этого должны изучить арифметику MISRA, а затем могут уйти, не понимая арифметику C. По-видимому, это не удалось, так как модель МИСРА-2004 («базовый тип») была заменена другой («основной тип») в МИСРА-2012. Таким образом, если ваша команда хорошо понимает C и использует хороший инструмент статического анализа (или даже несколько), способный выявить проблемные сценарии с помощью арифметики C, подход MISRA, скорее всего, не для вас.
TL;DR: следуйте стандартным рекомендациям, применяйте установленные хорошие правила. Определите конкретные критерии качества для различных частей вашей архитектуры. Для каждой части применяйте шаблоны, принципы и правила, подходящие для этой части. Изучите правила, прежде чем применять их. Не применяйте глупые правила. Используйте хороший статический анализ кода. Убедитесь, что ваша команда понимает C.
Как и в случае с вашим набором компиляторов или средой разработки и/или вашими инструментами статического анализа, подходящая версия должна быть выбрана в начале проекта, так как впоследствии ее будет сложно изменить!
Если вы начинаете проект с нуля, я бы порекомендовал принять MISRA C:2012 — возможно, также принять руководство нового (апрель 2016 г.) Соответствие MISRA
В новом руководстве по соблюдению также содержатся советы о том, как обращаться с принятым кодом (т. е. уже существующим или импортированным кодом).
Существующие проекты, которые были разработаны для более ранних версий, должны продолжать использовать эту более раннюю версию... если нет хорошего экономического обоснования для изменения. Изменение БУДЕТ привести к некоторой доработке!
