Esta lista de verificación debería ayudarlo a escribir programas de alta calidad.Rafael Finkel, 17/7/2005
- Identificadores: asegúrese de que todos sus identificadores sean significativos.
- Los identificadores de una letra casi nunca son significativos.
- Los nombres como bandera y temperatura rara vez son significativos. En lugar de la bandera, considere nombrar la condición booleana que verifica, como valueFound.
- Considere los identificadores de varias palabras, como nameIndex. Los identificadores largos (dentro de lo razonable) tienden a ser muy legibles.
- Literales básicos: evite números distintos de 0 y 1 y cadenas que no sean “” en su programa, excepto cuando defina constantes.
- No utilice un entero literal como un límite de matriz.
- No use un entero literal como un parámetro de ejecución, como un tiempo de espera o un número de puerto.
- No utilice enteros literales para seleccionar entradas de menú.
- No use un entero literal para medir el tamaño de una cadena o algunos datos; use sizeof () y strlen () en C y C ++ y .length () y .size en Java.
- No utilice una cadena literal para un nombre de archivo. Sin embargo, puedes dar salida a cadenas literales.
- No utilice un entero literal para indexar en una matriz que contiene datos heterogéneos.
- No declarar un identificador con un nombre que denota un literal, como “treinta”.
- Modularización: un programa está construido a partir de componentes que interactúan.
- No pongas todo tu código en la rutina principal ().
- De hecho, no hagas que ninguna rutina haga demasiado trabajo. Si es más largo que aproximadamente 50 líneas, quizás sea demasiado largo.
- Si duplica el código varias veces, considere si un bucle funcionaría mejor o quizás una subrutina.
- Si descubre que está sangrando muy profundamente, lo más probable es que no esté utilizando subrutinas cuando debería.
- No reinvente las rutinas de la biblioteca (a menos que su asignación lo requiera). Mire los manuales para aprender sobre sprintf () y atoi (), por ejemplo.
- Use los archivos de encabezado en C y C ++ (los archivos de encabezado tienen nombres que terminan con .h) para definir todas las constantes que necesitan varios archivos y declarar todas las subrutinas exportadas entre archivos. Pero no coloque el cuerpo de las subrutinas en los archivos de cabecera (con la rara excepción de las subrutinas en línea).
- Formato: Su programa debe ser fácil de leer.
- Consulte http://geosoft.no/development/javastyle.htmlpara obtener sugerencias claras sobre el formato y otros problemas de presentación. Esta referencia está dirigida específicamente a Java, pero también tiene valor para otros lenguajes.
- Intenta restringir todas tus líneas a 80 caracteres; muchas personas ven el código en ventanas de 80 columnas por razones históricas.
- No utilice las pestañas y los espacios para la sangría, ya que no todos los editores de texto tratan las pestañas como exactamente 8 espacios.
- Siga un patrón de sangrado consistente que refleje la estructura de control del programa.
- No ponga muchas líneas en blanco en su programa. Una línea en blanco entre las subrutinas es suficiente.
- Diferentes sistemas operativos terminan líneas de diferentes maneras. Si se mueve entre Win32 (que usa \ r \ n), Unix (que usa \ n) y MacOS (que usa \ r), reformatee su archivo para usar un método de terminación consistente.
- No establezca el bit ejecutable (Unix) en sus archivos de origen.
- Codificación: desea que su codificación sea clara, fácil de mantener y eficiente, en ese orden. Algunas de las reglas aquí son muy específicas; Otros son más generales.
- No use una secuencia de instrucciones if que no tengan otra cosa si solo una puede coincidir; utilizar de otra manera si.
- Cuando desee clasificar el ingreso de texto, no enumere los primeros caracteres posibles.
- Use los operadores de cambio en lugar de la multiplicación para construir patrones de bits.
- En una instrucción de cambio, compruebe siempre el caso predeterminado. Del mismo modo, en una secuencia de instrucciones if-then-else, use una final else.
- Todas las llamadas al sistema pueden fallar. Siempre verifique el código de retorno y use perror () para reportar el fallo.
- Los booleanos siempre deben usar el tipo booleano en Java, bool en C ++ y 0/1 enteros en C. No use los caracteres t y f, y no use -1 y 1.
- Use bucles para inicializar estructuras de datos si es posible.
- Utilice cada variable y cada campo de una estructura para exactamente un propósito. No los sobrecargue a menos que haya una excelente razón para hacerlo.
- No utilice el mismo identificador para un tipo, una variable y un nombre de archivo, incluso si cambia el uso de mayúsculas. Es demasiado confuso.
- Si está modificando datos con htonl () o una rutina similar antes de la transmisión de red, no modifique los datos en su lugar. Construye una segunda estructura de datos.
- Trate de no usar variables globales o no locales. Declara cada variable en el alcance más pequeño que puedas. Existen usos legítimos de las variables no locales, pero asegúrese de que realmente las necesite.
- Los programas Shell, Perl y Python deberían tener su #! línea como la primera línea del archivo; De lo contrario, la línea es solo un comentario.
- Intenta evitar codificar casos especiales. A menudo, puede utilizar pseudodatos u otros métodos de estructura de datos que le permiten plegar casos especiales en los casos regulares.
- Compiladores: que te ayuden a encontrar errores.
- Siempre invocar compiladores con todas las advertencias habilitadas. Para C y C ++, use la bandera -Wall. Para Java, use -Xlint: all -deprecation, y use el programa pmd para obtener sugerencias para un mejor estilo. Para Python, use -t -W all.
- Todos los programas de Perl deben ejecutarse con el indicador -w y deben tener un uso estricto. Todos los scripts de Perl cgi-bin también deben tener la marca -T.
- La utilidad make: Úsala y úsala bien.
- Un makefile siempre debe tener una receta “limpia”, que debe eliminar todos los archivos que pueden reconstruirse con otras recetas en el makefile, incluidos los archivos de objetos y ejecutables.
- Si su proyecto tiene varios archivos de origen, el makefile debe generar archivos de objetos (.o) según sea necesario y vincularlos entre sí.
- El archivo make se debe escribir de modo que si ejecuta make dos veces seguidas, la segunda ejecución no se vuelva a compilar.
- Cada receta debe crear el archivo especificado en su destino.
- Cada receta debe usar cada archivo especificado en su lista de requisitos previos.
- Aprenda a usar reglas para objetivos como .c.o para evitar archivos make repetidos.
- Si solo tiene un archivo fuente C o C ++, el archivo ejecutable debe tener el mismo nombre (sin la extensión .c o .cpp).
- Asegúrese de enumerar todos los archivos .h como requisitos previos donde se necesitan. Considere usar makedepend para generar la lista de requisitos previos para usted.
- Documentación: no es sólo para el graduador. ¡Te ayuda a medida que escribes el programa!
- Agregue documentación a medida que escribe el programa. Siempre puedes modificarlo a medida que tu diseño cambie.
- Incluya documentación externa: ¿Cómo se compila y ejecuta el programa, y qué se pretende que haga? La documentación externa podría estar en un archivo separado; Para proyectos pequeños, puede ser un comentario en el archivo fuente único.
- Incluya documentación interna: ¿Qué algoritmos y estructuras de datos está utilizando? Una descripción general puede estar en un archivo separado, pero generalmente la documentación interna se coloca en las rutinas, declaraciones y pasos específicos que describe.
- Revise todo su programa y la documentación para los errores de ortografía. Es descortés entregar un trabajo mal escrito, y esto implica una falta de atención a los detalles.
- Revise toda su documentación (y mensajes de salida) en busca de errores gramaticales.
- Los programas son mucho más legibles si pones un breve comentario sobre el cierre de llaves. Por ejemplo, la llave que cierra un condicional puede tener un comentario como “si el valor se ve bien”. Un refuerzo que cierra un bucle puede tener un comentario como “para cada línea de entrada”. Un corsé que cierra un procedimiento puede tener un comentario simplemente nombrando el procedimiento. Una abrazadera que cierra una clase puede tener un comentario que diga “clase” y luego el nombre de la clase.
Por alguna razón, esta página es popular entre los traductores.
Original Source: http://www.cs.uky.edu/~raphael/checklist.html
