Cómo programan los principales programadores de la NASA
Hola: El trabajo de un desarrollador de la NASA es uno de los más desafiantes en el mundo de la programación. Escriben código y desarrollan aplicaciones de misión crítica, siendo la seguridad su principal objetivo.
En este caso, es muy importante para ellos establecer pautas estrictas de codificación y seguirlas. Estas reglas cubren varios aspectos del desarrollo de software, como cómo se debe escribir el software, qué características del lenguaje se deben utilizar, etc.
Aunque es difícil llegar a un consenso sobre un estándar de codificación, el científico jefe del JPL de la NASA, Gerard J. Holzmann, ha desarrollado un conjunto de pautas de codificación denominadas "Diez reglas para desarrollar códigos críticos para la seguridad" seguidas unánimemente por todos. personal.
Debido a que el trabajo de JPL está relacionado con el lenguaje C, esta guía se centra en el código escrito en el lenguaje de programación C. Pero también se puede aplicar de forma flexible a otros idiomas.
Las diez principales pautas de codificación de la NASA son las siguientes:
1. Simplifique el flujo de control: utilice las construcciones de flujo de control más simples posibles para escribir programas; no utilice construcciones setjmp o longjmp, ni declaraciones goto. y Llamadas recursivas directas o indirectas.
2. Utilice un límite superior fijo para los bucles: Todos los bucles deben tener un límite superior fijo. Una herramienta de detección debe confirmar estáticamente que el bucle no puede alcanzar el límite superior de iteración preestablecido. Si este límite superior no puede demostrarse estáticamente, entonces se puede considerar que se ha violado este principio.
3. No realice la asignación de memoria dinámica una vez completada la inicialización.
4. No utilice funciones largas: si el formato estándar es una declaración por línea y una declaración por línea, entonces la longitud de la función debe estar dentro del alcance de una hoja de papel, es decir, las líneas de código de cada función no deben exceder las 60.
5. Baja densidad de aserciones: la densidad de aserciones en el código es tan baja como 2 aserciones por función en promedio. Las aserciones se utilizan para detectar condiciones anormales en la ejecución real. Las afirmaciones no deben tener efectos secundarios y deben definirse como pruebas booleanas. Cuando una aserción falla, se debe realizar una acción de recuperación explícita, como devolver una condición de error al llamador de la función que falló la aserción. Para las herramientas estáticas, cualquier afirmación que la herramienta estática pueda demostrar que nunca falla o nunca se activa viola esta regla (por ejemplo, es imposible satisfacer esta regla agregando declaraciones afirmativas (verdaderas) inútiles).
6. Declarar objetos de datos en el nivel de alcance mínimo: este principio es también el principio básico de la ocultación de datos. Todos los objetos de datos deben declararse en el nivel de alcance más pequeño posible.
7. Verificar parámetros y valores de retorno: El valor de retorno de una función no vacía debe verificarse después de cada llamada a la función, y la validez de los parámetros debe verificarse dentro de cada función.
8. Limitar el uso de preprocesadores: El uso de preprocesadores sólo está limitado al incluir archivos de encabezado y definiciones de macros simples. No se permiten la concatenación de símbolos, listas de argumentos variables (elipsas) ni llamadas a macros recursivas. Todas las macros deben expandirse para completar unidades de sintaxis. Generalmente no se recomienda el uso de directivas de compilación condicional, pero no siempre es posible evitar tener que tener un verificador basado en herramientas que lo marque cada vez que lo haga en su código, y por una buena razón.
9. Restringir el uso de punteros: Específicamente, no se permite más de un nivel de desreferenciación de punteros. Las operaciones de desreferenciación de punteros no se pueden ocultar en definiciones de macros o declaraciones de tipos. No se permiten punteros de función.
10. Compile todo el código: desde el primer día de desarrollo, compile el código con el compilador activando la opción de advertencia de nivel más alto. Bajo esta configuración, el código debe compilarse sin advertencias. El código debe pasar la herramienta de análisis estático del código fuente, verificarlo más de una vez al día y pasar sin advertencias.
¡Consúltalo!