Las 10 reglas de codificación de la NASA para redactar un programa crítico de seguridad

Los proyectos de software grandes y complejos utilizan varios estándares y pautas de codificación. Estas pautas establecen las reglas básicas que se deben seguir al escribir software. Por lo general, determinan:

a) ¿Cómo se debe estructurar el código?
b) ¿Qué función de idioma debería o no debería utilizarse?

Para que sea eficaz, el conjunto de reglas debe ser pequeño y lo suficientemente específico como para que pueda entenderse y recordarse fácilmente.

Los mejores programadores del mundo que trabajan en la NASA siguen un conjunto de pautas para desarrollar códigos críticos para la seguridad. De hecho, muchas agencias, incluido el Laboratorio de Propulsión a Chorro (JPL) de la NASA, se centran en el código escrito en lenguaje de programación C. Esto se debe a que existe un amplio soporte de herramientas para este lenguaje, como extractores de modelos lógicos, depuradores, compiladores estables, analizadores de código fuente sólidos y herramientas de métricas.

En casos críticos, se hace necesario aplicar estas reglas, especialmente cuando la vida humana puede depender de su corrección y eficiencia. Por ejemplo, los programas de software que se utilizan para controlar aviones, naves espaciales o plantas de energía nuclear.

Pero, ¿sabe qué estándares utilizan las agencias espaciales para operar sus máquinas? A continuación, enumeramos las 10 reglas de codificación de la NASA establecidas por el científico líder del JPL, Gerard J. Holzmann. Todos se centran principalmente en los parámetros de seguridad y también puede aplicarlos a otros lenguajes de programación.

Regla n. ° 1 - Flujo de control simple

Escriba programas con construcciones de flujo de control muy simples:no use setjmp o longjmp construcciones, ir declaraciones y recursividad directa o indirecta .

Razón: El flujo de control simple da como resultado una claridad de código mejorada y capacidades más sólidas para la verificación. Sin recursividad, no habrá gráfico de llamada de función cíclica. Por lo tanto, todas las ejecuciones que se supone que están limitadas siguen estando realmente limitadas.

Regla No. 2 - Límite superior fijo para bucles

Todos los bucles deben tener un límite superior fijo. Debería ser posible que una herramienta de verificación demuestre estáticamente que no se puede exceder un límite superior preestablecido en el número de iteraciones de un bucle.

La regla se considera violada si el lazo enlazado no se puede probar estáticamente.

Razón: La presencia de límites de bucle y la ausencia de recursividad previenen el código fuera de control. Sin embargo, la regla no se aplica a las iteraciones que están destinadas a no terminar (por ejemplo, el programador de procesos). En tales casos, se aplica la regla inversa:debe poder demostrarse estáticamente que la iteración no puede terminar.

Regla n.º 3:Sin asignación de memoria dinámica

No utilice la asignación de memoria dinámica después de la inicialización.

Razón: Asignadores de memoria como malloc , y los recolectores de basura a menudo tienen un comportamiento impredecible que puede afectar excepcionalmente al rendimiento. Además, los errores de memoria también pueden ocurrir debido a un error del programador, que incluye

• Intentar asignar más memoria de la que está disponible físicamente
• Olvidar la memoria libre
• Continuar usando la memoria después de que se liberó
• Sobrepasar los límites de la memoria asignada

Obligar a todos los módulos a vivir dentro de un área de almacenamiento fija y preasignada puede eliminar estos problemas y facilitar la verificación del uso de la memoria.

Una forma de reclamar memoria dinámicamente en ausencia de asignación de memoria del montón es usar memoria de pila.

Regla n. ° 4:No se permiten funciones grandes

Ninguna función debe ser más larga de lo que se puede imprimir en una sola hoja de papel en un formato de referencia estándar con una línea por declaración y una línea por declaración. Esto significa que una función no debe tener más de 60 líneas de código.

Razón: Las funciones excesivamente largas son a menudo un signo de una estructura deficiente. Cada función debe ser una unidad lógica que sea comprensible y verificable. Es bastante más difícil de entender una unidad lógica que abarca varias pantallas en una pantalla de computadora.

Regla n. ° 5 - Densidad de afirmación baja

La densidad de afirmaciones del programa debe promediar un mínimo de dos afirmaciones por función. Las afirmaciones se utilizan para comprobar si hay condiciones anormales que nunca deberían ocurrir en ejecuciones de la vida real. Deben definirse como pruebas booleanas. Cuando una aserción falla, se debe tomar una acción de recuperación explícita.

Si una herramienta de verificación estática demuestra que la afirmación nunca puede fallar o mantenerse, la regla se considera violada.

Razón: Según las estadísticas de esfuerzo de codificación de la industria, las pruebas unitarias capturan al menos un defecto por cada 10 a 100 líneas de código. Las posibilidades de interceptar defectos aumentan con la densidad de afirmaciones.

El uso de afirmaciones también es importante, ya que forman parte de una sólida estrategia de codificación defensiva. Se utilizan para verificar las condiciones previas y posteriores de una función, parámetro y valor de retorno de una función e invariantes de bucle. Las afirmaciones se pueden deshabilitar de forma selectiva después de probar el código de rendimiento crítico.

Regla n. ° 6:Declarar objetos de datos en el nivel de alcance más pequeño

Éste apoya el principio básico de ocultación de datos. Todos los objetos de datos deben declararse en el nivel de alcance más pequeño posible.

Razón: Si un objeto no está dentro del alcance, su valor no puede ser referenciado o dañado. Esta regla desalienta la reutilización de variables para múltiples propósitos incompatibles que pueden complicar el diagnóstico de fallas.

Leer:Los 20 mejores programadores informáticos de todos los tiempos

Regla n.º 7:comprobar parámetros y valor devuelto

Cada función de llamada debe verificar los valores de retorno de las funciones que no son nulas, y la validez de los parámetros debe verificarse dentro de cada función.

En su forma más estricta, esta regla significa incluso el valor de retorno de printf declaraciones y archivo cerrar deben comprobarse las declaraciones.

Razón: Si la respuesta a un error legítimamente no es diferente de la respuesta al éxito, se debe verificar explícitamente un valor de retorno. Este suele ser el caso de las llamadas para cerrar y printf . Es aceptable convertir explícitamente el valor de retorno de la función a void - indicando que el codificador explícitamente (no accidentalmente) decide ignorar un valor de retorno.

Regla No. 8 - Uso limitado del preprocesador

El uso del preprocesador debe limitarse a la inclusión de archivos de encabezado y definiciones de macros. No se permiten llamadas de macro recursivas, pegado de tokens ni listas de argumentos variables.

Debe haber una justificación para más de una o dos directivas de compilación condicional incluso en grandes esfuerzos de desarrollo de aplicaciones, más allá del modelo estándar, que evita la inclusión múltiple del mismo archivo de encabezado. Cada uno de estos usos debe estar marcado por un verificador basado en herramientas y justificado en el código.

Razón: El preprocesador de C es una herramienta poderosa y ambigua que puede destruir la claridad del código y confundir a muchos verificadores basados ​​en texto. El efecto de las construcciones en el código del preprocesador ilimitado podría ser excepcionalmente difícil de descifrar, incluso con una definición de lenguaje formal en la mano.

La precaución contra la compilación condicional es igualmente importante:con solo 10 directivas de compilación condicional, podría haber 1024 versiones posibles (2 ^ 10) del código, lo que aumentaría el esfuerzo de prueba requerido.

Leer:9 nuevos lenguajes de programación para aprender este año

Regla No. 9 - Uso limitado de punteros

Debe restringirse el uso de punteros. No se permite más de un nivel de desreferenciación. Las operaciones de desreferencia del puntero no deben ocultarse dentro de typedef declaración o definiciones de macro.

Los punteros de función tampoco están permitidos.

Razón: Los punteros se usan incorrectamente con facilidad, incluso por parte de los expertos. Hacen que sea difícil seguir o analizar el flujo de datos en un programa, especialmente mediante analizadores estáticos basados ​​en herramientas.

Los punteros de función también restringen el tipo de comprobaciones realizadas por analizadores estáticos. Por lo tanto, solo deben usarse si existe una fuerte justificación para su implementación. Si se utilizan punteros de función, es casi imposible que una herramienta demuestre la ausencia de recursividad, por lo que deben proporcionarse métodos alternativos para compensar esta pérdida de capacidades analíticas.

Leer:14 mejores software de programación para escribir código

Regla n. ° 10:compile todo el código

Todo el código debe compilarse desde el primer día de desarrollo. La advertencia del compilador debe habilitarse en la configuración más minuciosa del compilador. El código debe compilarse con esta configuración sin ninguna advertencia.

Todo el código debe verificarse diariamente con al menos un (preferiblemente más de uno) analizador de código fuente estático de última generación y debe pasar el proceso de análisis sin advertencia.

Razón :Hay muchos analizadores de código fuente eficaces disponibles en el mercado; algunos de ellos son herramientas gratuitas. No hay absolutamente ninguna excusa para que ningún codificador no haga uso de esta tecnología fácilmente disponible. Si el compilador o el analizador estático se confunden, el código que causa la confusión / error debe reescribirse para que sea más trivialmente válido.

Leer:30 inventos asombrosos de la NASA que usamos en nuestra vida diaria

¿Qué dice la NASA sobre estas reglas?