El presente documento recopila un conjunto de buenas prácticas de programación en lenguaje C
provenientes de diferentes fuentes que están especificadas al final del documento.
Estas normas pueden no ser estrictamente necesarias para que un programa funcione, pero son recomendables para tener menos errores y para que, si los hay, sea más fácil encontrarlos. Los profesores tendrán en cuenta en la corrección de los proyectos que usted emplee un buen estilo de programación.
La presente lista no está necesariamente completa, pero si contiene una cantidad significativa de
buenas prácticas de programación que deben seguir los estudiantes del curso.
1. Cada programa debe comenzar con un comentario que describa su propósito.
2. Hacer un diseño previo al programa (pseudo código, diagramas, ...). Se aconseja revisarla
antes de empezar a programar. Se empieza por la descomposición del problema en
funciones, para pasar luego al detalle de cada una. El pseudo código se emplea con
frecuencia para pensar el programa durante el proceso de diseño. Luego el programa en
pseudo código se convierte a su equivalente el C.
3. Su computadora y su compilador son buenos maestros. Si tras la lectura de su manual del
lenguaje C no está seguro del funcionamiento de alguna característica de C, experimente con
un pequeño programa de prueba y vea lo que sucede. Ajuste las opciones de su compilador
para que le devuelva el máximo de avisos. Estudie cada mensaje que aparezca al compilar
sus programas y corrija los errores y advertencias reportados para eliminar los mensajes.
4. Declare las variables con nombres significativos (o mnemotécnicos). Esto ayuda a que los
programas estén auto documentados, es decir, que resulte más fácil entenderlos simplemente
leyéndolos en lugar de tener que consultar manuales o hacer referencia a muchos
comentarios.
5. Como en álgebra, para hacer más clara a una expresión es aceptable agregarle paréntesis
aunque estos no sean imprescindibles. Dichos paréntesis se llaman paréntesis redundantes.
Estos se emplean normalmente para agrupar sub-expresiones de expresiones más grandes.
6. Capture los resultados de todas las llamadas al sistema que su programe realice, y aplique el
tratamiento que corresponda en cada caso.
7. Indente la instrucción del cuerpo de una estructura if para que resalte la estructura y
simplificar la lectura del programa.
8. Su programa no debe tener instrucciones no alcanzables, es decir, que nunca se ejecuten, ni
realizar varias veces la misma operación sobre los mismos datos.
9. Al escribir expresiones que contengan muchos operadores, consulte la tabla de precedencia
de los operadores. Confirme que los operadores de la expresión se ejecutan en el orden que
espera. Si no está seguro del orden de evaluación de una expresión compleja, coloque
paréntesis para forzar el orden, justo igual como lo haría en una expresión algebraica.
Además, observe que algunos operadores, como el de asignación (=), se asocian de derecha
a izquierda, y no de izquierda a derecha.
Página 110. La iniciación de variables cuando se declaran ayuda al programador a evitar los problemas
provocados por datos no inicializados.
11. En los programas no debe haber más que una instrucción por línea.
12. Sangre o indente las instrucciones de ambos cuerpos de las estructuras if/else.
13. Si hay varios niveles de sangrado, todos deben sangrarse con espacios iguales.
14. Siempre ponga llaves en las estructuras if/else (y en cualquier estructura de control) para
ayudarle a evitar su omisión accidental, especialmente si después le agrega instrucciones a
una cláusula if o else.
15. Inicialice todas las variables que use como los contadores y totalizadores.
16. Declare cada variable en una línea diferente.
17. Al efectuar divisiones entre una expresión cuyo valor podría ser cero, busque explícitamente
esta condición y manéjela de manera adecuada (imprimiendo un mensaje de error) en lugar
de permitir que suceda un error fatal.
18. Mediante un mensaje pídale al usuario todas las entradas de teclado. Dicho mensaje debe
especificar la forma de la entrada y los valores especiales que pueda tener (como el valor
centinela que debe indicar el usuario para terminar algún ciclo) .
19. En los ciclos controlados por un valor centinela, las solicitudes de entrada de información
deben recordarle explícitamente al usuario dicho valor centinela.
20. No compare la igualdad o desigualdad de los valores de punto flotante. En cambio, pruebe
que el valor absoluto de la diferencia sea menor que un valor pequeño especificado.
21. Controle los ciclos con contadores por medio de variables enteras.
22. Para ayudarle a evitar los errores por diferencia de uno, utilice el valor final en la condición
de una estructura while o for y el operador relacional <=. Por ejemplo, para un ciclo que
imprime los valores 1 a 10, la condición de continuación del ciclo debería ser contador <=
10, en lugar de contador < 10 (lo que es un error por diferencia de uno) o contador < 11
(que,sin embargo, es correcta) No obstante, muchos programadores prefieren el llamado
conteo basado en cero, en el que para contar 10 veces, habría que inicializar contador a cero
y la prueba de continuación del ciclo sería contador < 10.
23. En las secciones de iniciación e incremento de las estructuras for sólo ponga expresiones
relacionadas con las variables de control. Las manipulaciones de otras variables deben
aparecer antes del ciclo (si sólo se ejecutan una vez, como las instrucciones de
inicialización) o en el cuerpo del ciclo (si se ejecutan una vez por repetición, como en el
caso de las instrucciones de incremento o decremento) .
24. Aunque el valor de la variable de control puede cambiarse en el cuerpo del ciclo for, evite
hacerlo, pues esta práctica puede generar sutiles errores de lógica.
Página 225. Evite reinventar la rueda. Cuando sea posible, utilice las funciones de la biblioteca estándar
de C en lugar de escribir nuevas. Con esto se reduce el tiempo de desarrollo de los
programas. A menos que al hacerlo, no cumpla con los objetivos del proyecto en cuanto al
aprendizaje de las herramientas descritas en las clases.
26. Cada función debe limitarse a efectuar una sola tarea bien definida, y el nombre de dicha
función debe expresar claramente la tarea. Esto promueve la reutilización del software.
27. Si no puede seleccionar un nombre conciso que exprese lo que hace la función es posible
que ésta haga demasiadas tareas. Generalmente es mejor dividir dicha función en varias
partes más pequeñas.
28. Agregue un caso default en las instrucciones switch. Los casos no probados explícitamente
en una instrucción switch que no tenga un caso default son ignorados. Al incluir el caso
default se enfoca al programador en la necesidad de procesar condiciones excepcionales.
Hay situaciones en las que no es necesario el procesamiento default.
29. Aunque las cláusulas case y el caso default de la estructura switch pueden suceder en
cualquier orden, se considera una buena práctica de programación poner la cláusula default
al último.
30. La declaración de una variable como global en lugar de local permite que sucedan efectos
secundarios cuando una función, que no necesita tener acceso a ella, la modifica
accidentalmente o por malicia. En general, las variables globales deben evitarse, excepto en
ciertas situaciones en las que hay requerimientos de desempeño especiales.
31. Las variables que sólo se utilizan en una función particular deben declararse como variables
locales de dicha función, en lugar de cómo variables globales.
32. Los programas deben escribirse como conjuntos de funciones pequeñas. Esto hace más fácil
escribir, depurar, mantener y modificar los programas.
33. Las funciones que requieran de un gran número de parámetros podrían estar efectuando
demasiadas tareas. Considere dividir la función en funciones más pequeñas que realicen las
distintas tareas. El encabezado de la función debe caber en una línea, de ser posible.
34. Cualquier problema que pueda resolverse por recursividad también puede resolverse por
iteración (de manera no recursiva). Normalmente se prefiere un enfoque recursivo sobre un
enfoque iterativo cuando el primero refleja de manera más natural el problema y su
resultado es un programa más fácil de entender y depurar. Otra razón para seleccionar la
solución recursiva es que tal vez no se encuentre una solución iterativa aparente.
35. Todo valor constante que se use más de una vez deberá estar declarado al principio del
programa con #define.
Página 336. Los nombres usados para constantes, variables, tipos y funciones deben seguir las siguientes
reglas:
• Serán verbos para las funciones y nombres para tipos, variables y constantes.
• Se podrá abreviar una palabra en vez de ponerla completa, pero debe quedar claro su
significado.
• Los nombres de constantes deben ir en mayúscula.
• Los nombres de tipos tendrán la inicial mayúscula y el resto debe ir en minúsculas.
• Los nombres de variables y funciones deben ir en minúsculas.
• Las variables cuyo sentido no quede suficientemente aclarado con su nombre, deberá tener
un comentario explicativo junto a su declaración.
• Las funciones deben llevar un comentario indicando sus objetivos, así como a que resultados
pretenden llegar en función de los datos de entrada.
• Toda entrada de datos (individual o ciclo de ellas) con scanf debe ir precedida de un
mensaje de petición con printf.
37. Evite los identificadores que comiencen con uno o dos caracteres de subrayado, pues podría
ser que el compilador de C utilice nombres de este tipo para fines internos. Esto evitará que
los nombres que usted determine se confundan con los nombres que el compilador
seleccione.
38. Dentro de los corchetes que definen el cuerpo de una función, indente el cuerpo de la
función un nivel. Esto resalta la estructura funcional de los programas y ayuda a simplificar
su lectura.
39. Sólo indique letras mayúsculas para los nombres de constantes de enumeración. Con esto se
resaltan las constantes en el programa, recordándole al programador que las constantes de
enumeración no son variables.
40. Algunos programadores siempre incluyen llaves en las estructuras do/while, incluso cuando
no son necesarias. Esto ayuda a eliminar las ambigüedades entre la estructura while y la
estructura do/while que contiene una sola instrucción.
41. Algunos programadores prefieren declarar las variables en líneas separadas. Este formato
permite la fácil inserción de comentarios descriptivos junto a cada declaración.
42. Para hacer más legibles sus programas, ponga espacios después de las comas (, ) .
43. La consistencia en la aplicación razonable de convenciones de sangrado a sus programas
simplificará notablemente su lectura. Sugerimos una tabulación fija de 1⁄4 de pulgada o tres
espacios en blanco por cada sangría.
44. Cada función debería caber en una ventana del editor. Sin importar su tamaño, lo importante
es que efectúe bien una tarea. Las funciones pequeñas promueven la reutilización del
software.
45. Establezca una convención para el tamaño de las sangrías y luego aplíquela de manera
uniforme. La tecla Tab sirve para crear sangrías, pero las tabulaciones pueden variar.
Recomendamos manejar tabulaciones de 1⁄4 de pulgada o (de preferencia) de tres espacios
por cada nivel de sangría.
Página 446. Es posible distribuir una instrucción grande sobre varias líneas. Si tiene que dividir una
instrucción sobre varias líneas, seleccione puntos de ruptura que tengan sentido, como
después de una coma en el caso de una lista separada por comas o después de un operador
en el caso de una expresión larga. Si necesita dividir una instrucción en varias líneas, sangre
todas las líneas subsecuentes.
47. Algunos programadores prefieren colocar primero las llaves izquierda y derecha y después
introducir las instrucciones que van dentro de ellas. Con esto se evita la omisión de alguna
de dichas llaves.
48. Si hay demasiados niveles de anidamiento puede volverse difícil entender el programa.
Como regla general, trate de evitar codificar más de 5 niveles de sangrado.
49. Donde va una condición (if, while, for, ...) no se pondrá un número.
50. Ponga espacios en ambos lados de los operadores binarios. Con esto se resalta el operador y
se simplifica la lectura del programa.
51. Muchos programadores hacen que el último carácter impreso por una función sea un salto de
línea (\n). Esto asegura que la función dejará el cursor al inicio de una nueva línea. Las
convenciones de esta naturaleza promueven la reutilización del software, meta clave en los
entornos de desarrollo de software.
Recopilación hecha por el Prof. Ricardo Gonzalez para el Curso de Redes 1 CI4835
Puedes descargar el contenido en versión pdf
- Elaboración de Diagramas de Flujo para la Resolución de Problemas
- Lógica de Programación - Efraín Oviedo
- Errores Comunes de Programadores Novatos
Deja tus comentarios temas y aportes!!
Sign up here with your email
Déjame tus dudas y comentarios: Conversion Conversion Emoticon Emoticon