10 reglas de la NASA

Guía de buenas prácticas: Las 10 reglas de la NASA para escribir código crítico

En la sección de prácticas, incluimos estas 10 reglas extraídas de un famoso documento de la NASA. Son principios fundamentales pensados para el desarrollo de software crítico para la seguridad, como el que se usa en sistemas aeroespaciales.

Pueden servir como una gúia que tener siempre presente al escribir código que deba ser especialmente robusto, mantenible y seguro.

10 reglas de la NASA

Estas reglas no son solo para desarrollar cohetes: aplicar parte de esta disciplina puede ayudarte a mejorar la calidad de cualquier proyecto, incluso en tus prácticas académicas.

Las 10 reglas de la NASA

Usar solo estructuras de control simples.
No usar goto, setjmp, longjmp, ni recursión directa o indirecta.
Todos los bucles deben tener un límite superior fijo.
Nada de bucles potencialmente infinitos o dependientes de condiciones externas no controladas.
No usar memoria dinámica después de la inicialización.
Esto reduce riesgos como fugas de memoria o fallos impredecibles.
Ninguna función debe ser más larga de lo que cabe en una sola hoja de papel.
Como norma general, si no cabe en la pantalla, seguramente puedas simplificarla o dividirla en funciones más pequeñas.
Promedio mínimo de dos aserciones (assert) por función.
Las aserciones ayudan a capturar errores en tiempo de desarrollo.
Declarar los objetos de datos en el ámbito más reducido posible.
Es mejor declarar las variables lo más cerca posible de su uso.
Toda función debe validar los parámetros que recibe. Además, si devuelve un valor, el que haya invocado a la función debe validar el valor de retorno.
Uso limitado del preprocesador.
Solo para incluir headers y definir macros simples.
Limitar el uso de punteros a una sola desreferenciación y no usar punteros a función.
Compilar siempre con todas las advertencias activadas (-Wall).
Todas las advertencias (warnings) deben resolverse antes de liberar el software.

En cuanto al punto 5, el uso de asertos (assert), es interesante que sepas que no es lo mismo que las excepciones. Se suelen usar para cosas diferentes:

Asertos: para fallos de lógica, como por ejemplo un intento de dividir por cero, o los parámetros que ha recibido una función no son correctos.
Excepciones: para situaciones excepcionales (de ahí el nombre). Por ejemplo:
- Mientras estás transmitiendo datos de un sensor a otro dispositivo a través de una conexion wifi, se ha cortado la conexión.
- Mientras escribes datos en un pendrive, alguien lo ha desconectado.
- Estabas imprimiendo un documento y la impresora se ha quedado sin papel o sin tinta.