Los "ocho mandamientos" de los programadores en C

Ocho mandamientos del programador en lenguaje C

1. Debes ejecutar int con frecuencia y estudiar sus enseñanzas, porque su intuición y juicio suelen ser mucho más fuertes que los tuyos. Esto tiene sentido, pero muchos compiladores modernos encontrarán muchos de los mismos errores, y esto en sí mismo causa muchos errores debido a criterios de juicio obsoletos e inconsistentes, o la incapacidad de detectar áreas desconocidas.

Existen muchas otras herramientas como Sabre C que también son útiles. "A menudo" significa que debes escuchar sus enseñanzas todos los días, en lugar de esperar que Iint entregue el evangelio a tu código en el último momento. Realizarlo en un programa que nunca ha sido int generalmente resulta en inestabilidad del programa, por lo que debe evitarse a toda costa. Algunas personas han descubierto que es muy útil prestar más atención a las enseñanzas de int al depurar.

2. No debes acceder a punteros NULL, porque esto sólo conducirá al caos y la locura.

Obviamente este lema se copió incorrectamente. Debería ser "ulpointer", no puntero NULL, para evitar que la gente confunda los punteros nulos con el puntero NULL. Aparte de eso, éste no requiere más explicación. La ubicación señalada por el puntero nulo puede ser dragones, demonios, coredup e innumerables criaturas malvadas. Si asustas sus sueños, correrán desenfrenados en el programa. Un puntero nulo no apunta a 0 ni a ningún tipo, aunque algún código antiguo asume esta suposición.

3. No debes convertir todos los parámetros de función al tipo esperado, incluso si crees que no es necesario hacerlo para evitar la retribución que llegará tarde o temprano. Los programadores deben comprender la estructura de tipos del lenguaje que utilizan para evitar desgracias. Al contrario de lo que algunas personas piensan, int y long no son del mismo tipo. Hubo un período muy breve en la historia en el que el tamaño y la representación de int y long eran los mismos, pero algunas personas lo creían y esta opinión continuará, incluso ahora que las computadoras de 64 bits se han vuelto populares.

Además, a diferencia de las creencias de quienes viven en los pantanos contaminados del este (en referencia a Bell Labs, el lugar de nacimiento de Uiⅸ), NURL no es en realidad un tipo de puntero cuando se usa como parámetro de función. ser obligatorio Simplemente conviértalo al tipo correcto.

4. Si el archivo de encabezado no define un tipo de retorno para la función de la biblioteca, debe definirlo usted mismo cuidadosamente para evitar dañar el programa. El profeta Ansi C también nos enseñó en su sabiduría que se debe azotar al proveedor y pedirle que proporcione el archivo de encabezado de la función de biblioteca con el dolor de la expulsión. Después de todo, ellos son los únicos que saben la forma correcta de usar su magia. El profeta también dijo que no es prudente intentar agregar definiciones a las funciones usted mismo, y caerá en un infierno de errores interminables.

5. Debe verificar los límites de la matriz de todas las cadenas (y todas las matrices), porque es probable que alguien ingrese supercalifragilisticexpialidocious donde se debe ingresar 00. Como se menciona en los mandamientos sobre cadenas largas, la conclusión de este mandamiento es nunca usar gets0, porque es una herramienta del diablo. Su interfaz siempre debe comunicar los límites de la matriz a los servidores (funciones). Si el servidor no cumple, debe enviarse a un lugar de eliminación para que nunca pueda hacer nada malo.

6. Si una función afirma devolver un código de error cuando encuentra un problema, entonces debes verificar el código de error, incluso si hacerlo triplicará la cantidad de código. Si piensas: "No me puede pasar a mí", Dios definitivamente te castigará por tu arrogancia.

Los verdaderos creyentes quieren mejores mecanismos de error, porque verificar explícitamente los códigos de retorno es engorroso y no verificarlos es la mayor tentación. Pero hasta que llegue ese lejano día de la redención, debes recorrer el camino lleno de baches con paciencia y precaución, o de lo contrario el proveedor, la máquina o el software te darán un regalo inesperado la noche anterior a la defensa de tu tesis o a la entrega al cliente.

7. Debes aprender la biblioteca y tratar de no reinventarla, porque el código de la biblioteca es más corto y más fácil de entender, lo que te hace más feliz y más eficiente.

Innumerables paganos ven a los ganku con desdén y creen supersticiosamente que pueden hacerlo mejor ("más eficientemente"). La biblioteca C tiene algunas funciones mal escritas, pero usar la biblioteca es mucho más rápido y fácil que inventar su propia rueda cuadrada. Pero tenga muy en cuenta lo que la biblioteca puede y no puede hacer y evite utilizar funciones no confiables.

8. Te guste o no, debes utilizar el estilo 1TBR para que tus colegas puedan entender el propósito y la estructura del programa. Tu creatividad debe centrarse en resolver problemas, no en crear barreras para la comprensión. Este mandamiento crea algunas dudas entre los novicios y los conversos que no están familiarizados con el antiguo proverbio.

1TBR se refiere al estilo demostrado por los profetas de primera generación Brian Kernighan y Dennis Ritchie en sus artículos (es decir, una variante del estilo K&R). Mucha gente critica este estilo por ser difícil de usar, pero en realidad es un poco difícil de aprender. Una vez aprendido, es muy claro y fácil de entender. Si tengo que decir un defecto, es un poco propenso a errores.