Стандарт Misra для встроенного программного обеспечения

У меня есть требование сделать большой код кода MISRA совместимым.
Первый вопрос: может кто-то дать оценку для передачи хорошо написанного кода для встроенной системы на основе опыта. Я понимаю, что «хорошо написано» плохо определено и неопределенно, поэтому я прошу провести оценку.
Второй вопрос: любая рекомендация для инструмента, который может быть настроен (например, разрешить подавление конкретных предупреждений) и использоваться в среде автоматической сборки (например, интерфейс командной строки)
Любые другие полезные предложения, которые могут помочь в решении этой задачи.
Спасибо Илье.

    Я также настоятельно рекомендую PC-Lint. Если вы собираетесь компилировать свой код с помощью Visual Studio, я рекомендую подключаемый модуль «Visual Lint» от Riverblade. Если вы не можете скомпилировать код в Visual Studio, вы все равно можете запустить PC-Lint из командной строки для хорошего эффекта.

    Некоторые встроенные системные компиляторы обеспечивают проверку соответствия MISRA как предупреждения компилятора. Я использую компилятор IAR для разработки Arm7 / Arm9. Он позволяет легко настроить контрольный список соответствия MISRA прямо в настройке компилятора.

    Трудно придумать эмпирическое правило для оценки времени, которое потребовалось бы, чтобы сделать хорошо написанный код MISRA совместимым. Многое зависит от существующих привычек кодирования программистов и того, насколько они в первую очередь следуют правилам MISRA.

    Грубые оценки:
    2 – 3 дня, чтобы стать опытным в использовании PC-Lint.
    Первоначальный пропуск при составлении существующего кода MISRA совместим: от 10 до 25 процентов времени, затрачиваемого на запись кода в первую очередь.
    Сохранение кода MISRA соответствует: от 5 до 10 процентов добавлено в разработку кода. Половина этой стоимости изменяет привычки ваших кодеров, чтобы следовать «пути MISRA» в том, чтобы делать что-то. Другая половина – это дополнительная стоимость тестирования кода и проверки для обеспечения соответствия MISRA.

    Приведение кода Misra в соответствие с этим не слишком тяжело – если вы придерживаетесь достаточно хороших методов программирования. Возможно, некоторые правила указателей немного сложны, если код, который вы пытаетесь выполнить, имеет какую-то странную и замечательную арифметику указателя.

    Я бы предпочел рекомендацию Грега для ПК Lint, но с открытым исходным кодом Splint также стоит посмотреть, хотя между ними (и с системой предупреждения компилятора), по моим оценкам, вы по-прежнему сможете охватить только 80% правил Misra – остальное, вероятно, необходимо будет проверить код вручную.

    Я использую PC Lint для статического анализа кода на C и C ++. Он может быть настроен так, чтобы показывать, какие правила MISRA были нарушены, и имеет интерфейс командной строки.

    Я использовал коммерческий инструмент под названием QAC . Инструмент способен обеспечить соблюдение MISRA

    Он имеет интерфейс командной строки, поэтому вы можете настроить его для запуска из автоматизированной среды сборки. Правила, которые необходимо применять, настраиваются, но ожидайте, что кто-то потратит некоторое время на настройку u. Применения MISRA довольно просты и достаточно хорошо работают. Мне сказали (и это всего лишь 3-я arm), что это один из инструментов, используемых некоторыми агентствами (такими как FDA) для оценки кода. Как и большинство инструментов статического анализа, есть шум (ложные срабатывания). В прошлый раз, когда я использовал его, у него не было хороших средств, чтобы пометить / остановить ложный позитив от повторения (без изменения кода, на который он жаловался).

    Я подозреваю, что младший инженер займет до недели (4-5 дней), чтобы настроить его (при условии, что они настроены на то, чтобы заставить его работать, как вы хотите).

    С другой стороны, другие инструменты для коммерческого статического анализа, вероятно, также применяют MISRA. Сообщается, что (по их репутации), Klocwork .

    У нас была аналогичная проблема переоснащения правил Misra. У нас были некоторые проблемы с качеством кода в большом проекте, и мы решили использовать MISRA для улучшения качества кода.

    Мы используем компилятор Green Hills, который поддерживает правила MISRA C. Есть также автономные шашки. В зависимости от того, что вы хотите сделать, это может быть чуть-чуть убить, переключая все правила. Мы включили одно правило в то время, чтобы дать людям время исправить ограниченное количество подобных проблем, иначе вы полностью забудете количество ошибок.

    Поскольку наши предупреждения были сгенерированы компилятором, а не автономным инструментом, вы видите ошибки, которые вы разрабатываете, и не только при запуске проверки. По мере того, как мы продолжали развиваться, мы получили наш код, совместимый, а не один большой взрыв. Это также мешает старым привычкам испортить новый код, что приведет к необходимости повторного использования кода позже.

    Иногда бывает сложно получить старый код, поскольку никто точно не знает, как работает код. Надеюсь, у вас есть модульные тесты.

    Я ценю, что это старый вопрос, но для пользы любых других археологов (или искателей) важно помнить, что MISRA предоставляет рекомендации, которые не всегда следует слепо следовать.

    Я рекомендую писать новый код с MISRA; поэтому будет намного легче оставаться совместимым.

    Однако это не всегда возможно – и, в частности, при попытке перепроектировать код для соответствия рекомендациям. В этом случае я предлагаю вам сосредоточиться на обязательных правилах и рассматривать Advisories в качестве бонуса … cost v.

    Кроме того, имейте в виду, что существует процесс отклонения – лучше сохранить чистый и поддерживаемый код с отклонениями, чем усовершенствовать некоторые совместимые, но неparsingчивые спагетти.