10 правил кодирования НАСА для написания критически важных программ для безопасности

В крупных и сложных программных проектах используются различные стандарты и рекомендации по кодированию. Эти руководящие принципы устанавливают основные правила, которым необходимо следовать при написании программного обеспечения. Обычно они определяют:

а) Как следует структурировать код?
б) Какую языковую функцию следует или не следует использовать?

Чтобы быть эффективным, набор правил должен быть небольшим и достаточно конкретным, чтобы его можно было легко понять и запомнить.

Лучшие программисты мира, работающие в НАСА, следуют ряду рекомендаций по разработке критически важного для безопасности кода. Фактически, многие агентства, в том числе Лаборатория реактивного движения НАСА (JPL), сосредотачиваются на коде, написанном на языке программирования C. Это связано с тем, что для этого языка имеется обширная поддержка инструментов, таких как экстракторы логических моделей, отладчики, стабильный компилятор, надежные анализаторы исходного кода и инструменты для измерения показателей.

В критических случаях возникает необходимость применять эти правила, особенно когда человеческая жизнь может зависеть от их правильности и эффективности. Например, программное обеспечение, используемое для управления самолетами, космическими кораблями или атомными электростанциями.

Но знаете ли вы, какие стандарты используют космические агентства для управления своими машинами? Ниже мы перечислили 10 правил кодирования НАСА, установленных ведущим ученым JPL Джерардом Дж. Хольцманном. Все они в первую очередь ориентированы на параметры безопасности, и вы также можете применить их к другим языкам программирования.

Правило № 1 - Простой поток управления

Пишите программы с очень простыми конструкциями потока управления - не используйте setjmp или longjmp конструкции, goto операторы, а также прямая или косвенная рекурсия .

Причина: Простой поток управления приводит к повышению ясности кода и расширению возможностей проверки. Без рекурсии не будет циклического графа вызовов функций. Таким образом, все исполнения, которые должны быть ограничены, остаются фактически ограниченными.

Правило № 2 - Фиксированная верхняя граница для петель

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

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

Причина: Наличие границ цикла и отсутствие рекурсии предотвращают неконтролируемый код. Однако это правило не применяется к итерациям, которые не должны завершаться (например, планировщик процессов). В таких случаях применяется обратное правило - должно быть статически доказано, что итерация не может завершиться.

Правило № 3 - Не выделять динамическую память

Не используйте динамическое выделение памяти после инициализации.

Причина: Распределители памяти, такие как malloc , а сборщики мусора часто ведут себя непредсказуемо, что может исключительно повлиять на производительность. Кроме того, ошибки памяти также могут возникать из-за ошибки программиста, в том числе

• Попытка выделить больше памяти, чем доступно физически
• Забывают освободить память
• Продолжение использования памяти после ее освобождения
• Превышение границ выделенной памяти

Принуждение всех модулей размещаться в фиксированной заранее выделенной области хранения может устранить эти проблемы и упростить проверку использования памяти.

Один из способов динамически запрашивать память при отсутствии выделения памяти из кучи - использовать стековую память.

Правило № 4 - Никаких больших функций

Никакая функция не должна быть длиннее, чем то, что может быть напечатано на одном листе бумаги в стандартном справочном формате с одной строкой на объявление и одной строкой на утверждение. Это означает, что функция не должна содержать более 60 строк кода.

Причина: Чрезмерно длинные функции часто являются признаком плохой структуры. Каждая функция должна быть логической единицей, понятной и поддающейся проверке. Сложнее понять логическую единицу, занимающую несколько экранов на экране компьютера.

Правило № 5 - Низкая плотность утверждения

Плотность утверждений программы должна составлять минимум два утверждения на функцию. Утверждения используются для проверки ненормальных условий, которые никогда не должны происходить при выполнении в реальной жизни. Их следует определить как логические тесты. В случае сбоя утверждения следует предпринять явное действие по восстановлению.

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

Причина: Согласно отраслевой статистике усилий по кодированию, модульные тесты выявляют по крайней мере один дефект на 10–100 строк кода. Шансы на обнаружение дефектов увеличиваются с увеличением плотности утверждений.

Использование утверждений также важно, поскольку они являются частью сильной стратегии защитного кодирования. Они используются для проверки условий до и после функции, параметра и возвращаемого значения функции и инвариантов цикла. Утверждения можно выборочно отключить после тестирования кода, критичного к производительности.

Правило № 6 - объявляйте объекты данных на минимальном уровне области действия

Это поддерживает основной принцип сокрытия данных. Все объекты данных должны быть объявлены на минимально возможном уровне области видимости.

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

Прочтите:20 величайших программистов всех времен

Правило № 7 - Проверьте параметры и возвращаемое значение

Возвращаемое значение (я) непустых функций должно проверяться каждой вызывающей функцией, а правильность параметров должна проверяться внутри каждой функции.

В самой строгой форме это правило означает даже возвращаемое значение printf выписки и файл закрыть утверждения должны быть проверены.

Причина: Если ответ на ошибку по праву не отличается от ответа на успех, следует явно проверить возвращаемое значение. Обычно это происходит с вызовами close и printf . Допускается явное приведение возвращаемого значения функции к void - указывает на то, что кодировщик явно (не случайно) решает игнорировать возвращаемое значение.

Правило № 8 - Ограниченное использование препроцессора

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

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

Причина: Препроцессор C - это мощный и неоднозначный инструмент, который может нарушить ясность кода и сбить с толку многие текстовые программы проверки. Влияние конструкций в неограниченном коде препроцессора может быть чрезвычайно сложно расшифровать, даже имея под рукой формальное определение языка.

Предостережение против условной компиляции не менее важно - всего с 10 директивами условной компиляции может быть 1024 возможных версии (2 ^ 10) кода, что увеличит требуемые усилия по тестированию.

Прочтите:9 новых языков программирования, которые стоит выучить в этом году

Правило № 9 - Ограниченное использование указателей

Использование указателей должно быть ограничено. Допускается не более одного уровня разыменования. Операции разыменования указателя не следует скрывать внутри typedef объявление или определения макроса.

Указатели на функции также не допускаются.

Причина: Указатели легко могут использоваться неправильно даже специалистами. Они затрудняют отслеживание или анализ потока данных в программе, особенно с помощью статических анализаторов на основе инструментов.

Указатели на функции также ограничивают тип проверок, выполняемых статическими анализаторами. Таким образом, их следует использовать только в том случае, если есть веские основания для их внедрения. Если используются указатели на функции, для инструмента становится практически невозможно доказать отсутствие рекурсии, поэтому должны быть предоставлены альтернативные методы, чтобы восполнить эту потерю аналитических возможностей.

Читайте:14 лучших программ для написания кода

Правило № 10 - Компилируйте весь код

Весь код нужно компилировать с первого дня разработки. Предупреждение компилятора должно быть включено в самой точной настройке компилятора. Код должен компилироваться с этими настройками без предупреждения.

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

Причина :На рынке доступно множество эффективных анализаторов исходного кода; некоторые из них являются бесплатными инструментами. Ни одному программисту не может быть оправдания, если он не воспользуется этой общедоступной технологией. Если компилятор или статический анализатор запутались, код, вызывающий путаницу / ошибку, должен быть переписан, чтобы он стал более корректным.

Читайте:30 удивительных изобретений НАСА, которые мы используем в нашей повседневной жизни

Что НАСА говорит об этих правилах?