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

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

Правило №1. Используйте простой порядок выполнения

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

Правило №2. Фиксированная верхняя граница для циклов

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

Правило №3. Запрет на динамическое выделение памяти

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

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

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

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

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

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

Правило №5. Малое количество утверждений

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

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

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

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

Правило №7. Проверка параметров и возвращаемого значения

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

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

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

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

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

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

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