Buenas Prácticas de Programación en Lenguaje C

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 conun 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 simplementeleyé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 1

10. 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ícitamenteesta 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 2

25. 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 3

36. Los nombres usados para constantes, variables, tipos y funciones deben seguir las siguientesreglas:

• 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 importantees 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 4

46. 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 delí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.

Página 5