10 правил, призванных облегчить проведение контроля и статического анализа кода.
Вот что об этих правилах говорят в NASA:
Правила можно сравнить с ремнём безопасности в машине: сначала немного неудобно, но вскоре они входят в привычку и уже трудно представить, как без них обходиться.
Эти правила были созданы в 2006 году Джерардом Дж. Хольцманном в Лаборатории реактивного движения (ЛРД) NASA. Они были направлены на то, чтобы искоренить те приёмы программирования на языке С, которые затрудняют проведение контроля и статического анализа кода.
Правила дополняют руководящие принципы MISRA C и включены в большой набор рекомендаций по написанию кода ЛРД.
Итак, перечислим эти правила:
- Избегать сложных конструкций ветвления, таких как
gotoили рекурсия. - Все циклы должны иметь фиксированные границы (во избежание бесконтрольного разрастания кода).
- Не использовать динамическое распределение памяти после инициализации.
- Каждая функция должна располагаться максимум на одной печатной странице.
- Использовать не менее двух утверждений (так называемых ассертов) на функцию во время выполнения.
- Ограничивать область видимости объектов с данными до минимально возможной.
- Проверять возвращаемое значение всех не-void функций или приводить их к типу void для указания на то, что возвращаемое значение бесполезно.
- Ограничивать использование препроцессора.
- Ограничить использование указателей: достаточно одного разыменовывания, а указатели на функции вообще не применять.
- Компилировать со всеми возможными включёнными предупреждениями. Со всеми предупреждениями нужно разбираться до выхода ПО.
Эти правила были определены для языка С, но некоторые из них могут быть использованы при разработке современных интернет-приложений и приложений для мобильных устройств. Вот те правила, которые выбрал я:
1. Избегать сложных конструкций ветвления
Если не будет на то необходимости, я не стану использовать рекурсию для выполнения задачи, с которой может справиться и простой for. Рекурсии очень опасны там, где у вас нет непосредственного доступа к машине: окажись вы, к примеру, на Марсе, или на Луне, или на дне морском!
2. Все циклы должны иметь фиксированные границы (чтобы не допустить бесконтрольного разрастания кода)
Похоже на первое правило: буду создавать циклы с фиксированными границами, чтобы не допустить бесконечных циклов или бесконтрольного разрастания кода.
4. Каждая функция должна располагаться максимум на одной странице
Уместив функцию на одной странице, будет легче сразу увидеть и понять все функциональные возможности того или иного метода вашей программы.
Если функция не умещается на странице, это будет означать, что вы добавляете слишком много действий в свой код.
Если вы не делите большую функцию на маленькие, то это может привести к возникновению ещё одной проблемы: дублированию кода.
6. Ограничивать область видимости объектов с данными до минимально возможной
Никогда не используйте var на JavaScript — всегда лучше использовать let, чтобы не допустить утечки или наложения переменных и даже их дублирования.
То же касается и других языков, таких как C#. Используйте самую минимальную область видимости для своих переменных, например, private или наиболее защищённую, например, protected.
10. Компилировать со всеми возможными включёнными предупреждениями. Со всеми предупреждениями нужно разбираться до выхода ПО
C помощью ESLintили подобных инструментов вы легко сможете получать предупреждения от своего кода.
Потом надо их всех удалить или устранить, даже если для вас они не имеют большого значения.
Вот теперь мы готовы отправить наш код на Марс!
Читайте также:
- Как работает JavaScript
- Как JavaScript повзрослел и стал настоящим языком
- Как не лажать с JavaScript. Часть 1
Перевод статьи Riccardo Giorato: The Power of 10 — NASA’s Rules for Coding
