El mítico Jet Propulsion Laboratory (JPL) de la NASA se dedica a la investigación y desarrollo para las misiones espaciales, en concreto todo lo que tiene que ver con naves robotizadas. Está ubicado en California y gestionado por la prestigiosa Universidad Caltech, y entre sus proyectos están la misión Cassini-Huygens que orbita Saturno, los Voyager lanzados en los 70 y que siguen enviando datos de más allá del sistema solar, la nave Juno que se está dirigiendo en estos momentos a Saturno, o los diversos rovers (Curiosity, Opportunity...) que se han enviado a Marte.
Entre todo ese desarrollo robótico y de propulsión, se responsabilizan también del software que ha guiado a la mayor parte de las misiones no tripuladas que ha realizado la NASA, lo cual les otorga un buen curriculum para enseñar cómo se escribe buen software ¿verdad?
Hace unos años, en 2006, lanzaron un pequeño documento de tan solo 6 páginas en el que recogen sus 10 reglas de oro para escribir código para sistemas críticos de seguridad, es decir, código de calidad, mantenible y con menos propensión a los fallos.
Las reglas están pensadas de entrada para el lenguaje C/C++, pero son bastante generales y se pueden aplicar a cualquier lenguaje y sistema, y deberíamos hacerle caso aunque no se trate de sistemas críticos. La mayoría de las reglas son de puro sentido común, pero lo cierto es que luego, en muchas ocasiones, no las aplicamos.
Te las resumimos a continuación:
- Evita las construcciones de flujo complejas, como GOTO y la recursividad, en la medida de lo posible.
- Todos los bucles deben tener límites fijos.
- Evita el uso de ubicación dinámica en memoria. Esto en lenguajes con recolector de basura y similares es menos crítico, pero aún así es posible crear fugas de memoria en cualquier lenguaje (¡hasta en JavaScript!) si no somos cuidadosos.
- Ninguna función debería ser tan larga que no pueda imprimirse en una sola carilla de una hoja. Esto es, como mucho unas 60 líneas (sin contar comentarios).
- La densidad media de aserciones en un código debería ser de al menos 2 por función. Las aserciones se utilizan para verificar situaciones anómalas en el código, que no deberían darse nunca en situaciones normales.
- Las variables deberían tener siempre el mínimo ámbito posible. Es decir, no le otorguemos más ámbito a una variable del que necesita, pues podría ser modificada por otro código con el que no contábamos.
- Verificar siempre parámetros y valores de retorno. Todas las llamadas a una función que devuelvan algo deberían ser comprobadas desde la función llamante para verificar que devuelven valores aceptables. Del mismo modo todos los parámetros que se pasan a una función deberían ser comprobados por ésta al principio de la misma.
- El uso del preprocesador se debe limitar a inclusiones de archivos de cabecera y definiciones de macros simples. Esto es más aplicable al mundo C/C++, pero se puede traducir en otros lenguajes en que releguemos al mínimo el uso de compilaciones/regiones condicionales y otras complejidades del compilador (por ejemplo, 10 directivas condicionales en un programa dan lugar a 2^10 versiones diferentes del mismo código, con la complejidad que ello conlleva para testearlo.
- El uso de punteros debe mantenerse al mínimo.
- Todo el código debe compilarse correctamente desde el día 1. Y además deberíamos habilitar todas las posibles advertencias del compilador y tratarlas como errores en la medida de lo posible. Este nivel de requerimiento hará que el código sea menos propenso a errores.
Puedes leer el documento original (en inglés) aquí: The Power of Ten - Rules for Developing Safety Critical Code (se trata de una copia del documento, que ya no está disponible en el sitio del JPL).
Además, unos años después lanzaron un documento todavía más detallado (de 22 páginas) con más reglas, especialmente enfocado en el lenguaje C, pero con consejos válidos para casi cualquier lenguaje. Puedes leerlo aquí: JPL Institutional Coding Standard for the C Programming Language.
Fecha de publicación: