You are on page 1of 9

Buenas Prácticas de Programación en Lenguaje C

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 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 revisarle 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 seudo 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 corríjalos para eliminar los mensajes.

4. Declaré 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 demasiados comentarios.

5. Como en álgebra, para hacer más clara a una expresión es aceptable agregarle paréntesis innecesarios. Dichos paréntesis se llaman paréntesis redundantes. Estos

7. Confirme que los operadores de la expresión se ejecutan en el orden que espera. La iniciación de variables cuando se declaran ayuda al programador a evitar los problemas provocados por datos no inicializados. . Si no está seguro del orden de evaluación de una expresión compleja. 12. todos deben sangrarse con espacios iguales. y no de izquierda a derecha. observe que algunos operadores. Sangre las instrucciones de ambos cuerpos de las estructuras if/else. 6. consulte la tabla de precedencia de los operadores. coloque paréntesis para forzar el orden. Capture los resultados de todas las llamadas al sistema que su programe realice y déle el tratamiento adecuado que corresponda en cada caso. 9. Idente la instrucción del cuerpo de una estructura if para que resalte la estructura y simplificar la lectura del programa. justo igual como lo haría en una expresión algebraica. 11. 13. que nunca se ejecuten. En los programas no debe haber más que una instrucción por línea. Además. se asocian de derecha a izquierda. Su programa no debe tener instrucciones no alcanzables. ni realizar varias veces la misma operación sobre los mismos datos. 8.se emplean normalmente para agrupar subexpresiones de expresiones más grandes. Si hay varios niveles de sangrado. es decir. como el de asignación (=). Al escribir expresiones que contengan muchos operadores. 10.

18. En los ciclos controlados por un valor centinela. 21.14. 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 el error fatal. las solicitudes de entrada de información deben recordarle explícitamente al usuario dicho valor centinela. Declare cada variable en una línea diferente. pruebe que el valor absoluto de la diferencia sea menor que un valor pequeño especificado. 16. Controle los ciclos con contadores por medio de variables enteras. Inicialice los contadores y totales. 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. 15. especialmente si después le agrega instrucciones a una cláusula if o else. No compare la igualdad o desigualdad de los valores de punto flotante. Siempre ponga llaves en las estructuras if/else (y en cualquier estructura de control) para ayudarle a evitar su omisión accidental. 20. . Mediante un mensaje pídale al usuario todas las entradas de teclado. En cambio. 17.

en lugar de contador < 10 (lo que es un error por diferencia de uno) o contador < 11 (que.22. Evite reinventar la rueda. pues esta práctica puede generar sutiles errores de lógica. 26. Generalmente es mejor dividir dicha función en varias partes más pequeñas. como en el caso de las instrucciones de incremento o decremento) 24. utilice el valor final en la condición de una estructura while o for y el operador relacional <=. . habría que inicializar contador a cero y la prueba de continuación del ciclo sería contador < 10. Para ayudarle a evitar los errores por diferencia de uno. 23. 27. Si no puede seleccionar un nombre conciso que exprese lo que hace la función es posible que ésta haga demasiadas tareas. utilice las funciones de la biblioteca estándar de C en lugar de escribir nuevas. Las manipulaciones de otras variables deben aparecer antes del ciclo (si sólo se ejecutan una vez. Por ejemplo. en el que para contar 10 veces. y el nombre de dicha función debe expresar claramente la tarea. como las instrucciones de inicialización) o en el cuerpo del ciclo (si se ejecutan una vez por repetición. A menos que al hacerlo. sin embargo. Aunque el valor de la variable de control puede cambiarse en el cuerpo del ciclo for. para un ciclo que imprime los valores 1 a 10. evite hacerlo. muchos programadores prefieren el llamado conteo basado en cero. no cumpla con los objetivos del proyecto en cuanto al aprendizaje de las herramientas descritas en las clases. Cuando sea posible. Con esto se reduce el tiempo de desarrollo de los programas. Esto promueve la reutilización del software. la condición de continuación del ciclo debería ser contador <= 10. es correcta) No obstante. En las secciones de iniciación e incremento de las estructuras for sólo ponga expresiones relacionadas con las variables de control. 25. Cada función debe limitarse a efectuar una sola tarea bien definida.

28. En general. excepto en ciertas situaciones en las que hay requerimientos de desempeño especiales. Aunque las cláusulas case y el caso default de la estructura switch pueden suceder en cualquier orden. 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. Los casos no probados explícitamente en una instrucción switch que no tenga un caso default son ignorados. 33. de ser posible. las variables globales deben evitarse. Esto hace más fácil escribir. depurar. Las funciones que requieran de un gran número de parámetros podrían estar efectuando demasiadas tareas. Al incluir el caso default se enfoca al programador en la necesidad de procesar condiciones excepcionales. se considera una buena práctica de programación poner la cláusula default al último. 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 . la modifica accidentalmente o por malicia. 31. 34. Agregue un caso default en las instrucciones switch. Los programas deben escribirse como conjuntos de funciones pequeñas. Hay situaciones en las que no es necesario el procesamiento default. 29. mantener y modificar los programas. 30. en lugar de cómo variables globales. 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. 32. Las variables que sólo se utilizan en una función particular deben declararse como variables locales de dicha función.

tipos y funciones deben seguir las siguientes reglas: â ¢ Serán verbos para las funciones y nombres para tipos. Otra razón para seleccionar la solución recursiva es que tal vez no se encuentre una solución iterativa aparente. â ¢ Los nombres de constantes ir en mayúscula.depurar. variables y constantes. 36. . â ¢ Las funciones deben llevar un comentario indicando sus objetivos. â ¢ Se podrá abreviar una palabra en vez de ponerla completa. pero debe quedar claro del significado. deberá tener un comentario explicativo junto a su declaración. variables. Los nombres usados para constantes. en â ¢ Los nombres de variables y funciones ir en minúsculas. 35. Todo valor constante que se use más de una vez deberá estar declarado al principio del programa con #define. â ¢ Los nombres de tipos tendrán la inicial mayúscula y el resto ir Ì minúsculas. â ¢ Las variables cuyo sentido no quede suficientemente aclarado con su nombre. así como a que resultados pretenden llegar en función de los datos de entrada.

Para hacer más legibles sus programas. ) 43. Esto evitará que los nombres que usted determine se confundan con los nombres que el compilador seleccione. ponga espacios después de las comas (. Evite los identificadores que comiencen con uno o dos caracteres de subrayado. 42. Algunos programadores siempre incluyen llaves en las estructuras do/while. incluso cuando no son necesarias. Con esto se resaltan las constantes en el programa. Este formato permite la fácil inserción de comentarios descriptivos junto a cada declaración. Esto resalta la estructura funcional de los programas y ayuda a simplificar su lectura. idente el cuerpo de la función un nivel. 41.â ¢ Toda entrada de datos (individual o ciclo de ellas) con scanf ir precedida de un mensaje de petición con printf. Dentro de los corchetes que definen el cuerpo de una función. 38. 40. . Sólo indique letras mayúsculas para los nombres de constantes de enumeración. 39. Sugerimos una tabulación fija de 1â 4 de pulgada o tres espacios en blanco por cada sangría. 37. recordándole al programador que las constantes de enumeración no son variables. pues podría ser que el compilador de C utilice nombres de este tipo para fines internos. La consistencia en la aplicación razonable de convenciones de sangrado a sus programas simplificará notablemente su lectura. Algunos programadores prefieren declarar las variables en líneas separadas. Esto ayuda a eliminar las ambigà edades entre la estructura while y la estructura do/while que contiene una sola instrucción.

49.44. Ponga espacios en ambos lados de los operadores binarios. 50. Cada función debería caber en una ventana del editor. while. Como regla general. 45. Si hay demasiados niveles de anidamiento puede volverse difícil entender el programa. Sin importar su tamaño. Con esto se evita la omisión de alguna de dichas llaves. Donde va una condición (if. Es posible distribuir una instrucción grande sobre varias líneas. for. .. Muchos programadores hacen que el último carácter impreso por una función sea un saldo de línea (\n) Esto asegura que la función dejará el cursor al inicio de una . pero las tabulaciones pueden variar. Si tiene que dividir una instrucción sobre varias líneas.. Recomendamos manejar tabulaciones de 1â 4 de pulgada o (de preferencia) de tres espacios por cada nivel de sangría. trate de evitar codificar más de 5 niveles de sangrado. 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. 48. seleccione puntos de ruptura que tengan sentido. lo importante es que efectúe bien una tarea.) no se pondrá Ì un número. Las funciones pequeñas promueven la reutilización del software. 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 resalta el operador y se simplifica la lectura del programa. sangre todas las líneas subsecuentes. 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. 46. 51. Si necesita dividir una instrucción en varias líneas.

ve/url?sa=t&source=web&ct=res&cd=6&url=http%3A%2F%2Fpers onales.nueva línea.pdf&ei=O77ASojGJJfk8Ab2tmyAQ&rct=j&q=buenas+practicas+de+programacion+en+c&usg=AFQjCNH9W7LPMNx8RT CwELXIfTynrSdDmQ http://www.mx%2Fc%2Ffunciones%2Farchivos%2520%2528.google.pdf%2529%2Fcomplemento%25 20lecciones%252010-17.php?inpopup=true&id=3623 http://www. http://pis.co.co.google.edu. Las convenciones de esta naturaleza promueven la reutilización del software. meta clave en los entornos de desarrollo de software. Enlaces a Otros Documentos que contienen Buenas Prácticas de Programación en C y que fueron usado como base para la elaboración de este documento.es%2Fzorrillm%2FPDFs%2FDocencia%2FProgramacionComputadoras%2Fes tilo. 52. Los operadores unarios deben ponerse junto a sus operandos. sin espacios intermedios.co/moodle/mod/resource/view.bnct.ipn.unican.ve/url?sa=t&source=web&ct=res&cd=1&url=http%3A%2F%2Fazul2 .pdf&ei=O77ASojGJJfk8Ab2tmyAQ&rct=j&q=buenas+practicas+de+programacion+en+c&usg=AFQjCNF2kVSUyyGIxW9 DL0TT53vKNKYbFQ .unicauca.