У разработчиков NASA одна из самых сложных работ в мире программирования. Они пишут код и разрабатывают критически важные приложения, в первую очередь заботясь о безопасности и надежности.
В такой ситуациях важно соблюдать некоторые правила программирования, которые охватывают различные аспекты разработки программного обеспечения. Например, как писать программное обеспечение, какие функции следует использовать и т.д.
Несмотря на то, что трудно достичь консенсуса по поводу хорошего стандарта оформления кода, Лаборатория реактивного движения НАСА (JPL) следует руководству под названием «Сила десяти — правила безопасной разработки критического кода».
В этом руководстве основное внимание уделяется коду, написанному на языке C, из-за долгой работы JPL с этим языком. Но эти рекомендации могут быть легко применены и к другим языкам программирования.
Эти строгие правила программирования заложенные ведущим ученым JPL Жераром Дж. Хольцманном и направлены на обеспечение безопасности.
10 правил NASA для написания критически важного кода
- Ограничьте весь код очень простыми функциями управления потоком выполнения — не используйте операторы goto, setjmp или longjmp, а также прямую или косвенную рекурсию.
- Все циклы должны иметь фиксированную верхнюю границу. Инструмент проверки должен просто проверять, что заданная верхняя граница числа итераций цикла не может быть превышена. Если граница цикла не может быть доказана статически, правило считается нарушенным.
- Не используйте динамическое выделение памяти после инициализации.
- Ни одна функция не должна быть длиннее, чем та, которая может быть напечатана на одном листе бумаги в стандартном формате с одной строкой на выражение и одной строкой на объявление. Как правило, это означает не более 60 строк кода на функцию.
- В функции должно быть не более двух ассертов. Такие ассерты (защиты) используются для проверки аномальных условий, которые никогда не должны возникать в реальных условиях. Ассерты не должны содержать побочных эффектов и должны быть определены как булевы тесты. Когда ассерт не выполняется, должно быть предпринято явное действие по восстановлению, например, путем возврата ошибки вызывающей стороне. Любая защита, для которой инструмент статической проверки может доказать, что она никогда не нарушается или наоборот нарушается всегда, нарушает это правило (т.е. невозможно выполнить правило, добавив бесполезные выражения «assert (true)»).
- Объекты данных должны быть объявлены с минимально возможным уровнем области видимости.
- Возвращаемое значение не пустых функций должно проверяться каждой вызывающей функцией, а валидность параметров должна проверяться внутри каждой функции.
- Использование препроцессора должно быть ограничено включением header-файлов и простых макро определений. Вставка токенов, списков вариативных функций и рекурсивные вызовы недопустимы. Все макросы должны расширяться в полные синтаксические единицы. Использование директив условной компиляции часто также сомнительно, но не всегда этого можно избежать. Это означает, что редко можно найти оправдание для более чем одной или двух директив условной компиляции, даже в больших проектах по разработке. Каждое такое использование должно быть помечено средством проверки и обосновано в коде.
- Использование указателей должно быть ограничено. В частности, допускается не более одного уровня разыменования. Операции разыменования указателя не могут быть скрыты в определениях макросов или внутри объявлений typedef. Указатели на функции не допускаются.
- Весь код должен компилироваться с первого дня разработки, и все предупреждения должны быть включены в самой строгой настройке компилятора. Весь код должен компилироваться с этими настройками без каких-либо предупреждений. Весь код должен ежедневно проверяться, по крайней мере, одним, но предпочтительно более чем одним, современным статическим анализатором исходного кода и должен проходить анализ с нулевыми предупреждениями.
Вот что говорит НАСА об этих правилах:
Правила действуют как ремень безопасности в вашей машине: вначале они, возможно, немного неудобны, но через некоторое время их использование становится незаметным, и отказ от них становится невообразимым.
