Este documento presenta 10 reglas de estilo de programación para escribir código de alta calidad. Estas reglas incluyen modularizar el programa en subprogramas, evitar variables globales, usar nombres significativos, definir constantes al principio, evitar el uso de goto, usar parámetros adecuadamente, usar funciones para devolver valores únicos, tratar errores adecuadamente, hacer el código legible y documentarlo. El objetivo general es producir código limpio, consistente, extensible y correcto para facilitar la lectura y modificación por otros program

1. Unidad 2:
Estándares de Calidad en el Diseño de
Algoritmos y Construcción de Programas
2.2.- Estilos de Programación
Conocer las reglas de los estilos de programación
para la escritura de programas de calidad.
Profa. Yenny Salazar

2. Contenido
 Estilos de Programación.
 Importancia de Escribir Buen Código.
 Cualidades de un Buen Código.
 Reglas de Estilo de Programación.
1. Modularizar un programa en subprogramas.
2. Evitar variables globales en subprogramas.
3. Usar nombres significativos para identificadores.
4. Definir constantes con nombres al principio del programa.
5. Evitar el uso del goto y no escribir nunca código spaghetti.
6. Uso adecuado de parámetros variable.
7. Uso adecuado de funciones.
8. Tratamiento de errores.
9. Legibilidad.
10. Documentación.
 Generalidades.
 Actividades.
 Referencias.

3. Estilos de Programación
También llamado estándares de código, guías de estilo o convención
de código, es un término que describe convenciones para escribir
código fuente en ciertos lenguajes de programación; es decir, a la
forma en que se da formato al código fuente. El código con un formato
desordenado no es aceptable, debido a que es difícil de leer.
El estilo generalmente depende del lenguaje de programación que se
use para escribir el código, pero debe ser consistente en todo el
código, incluyendo sus módulos y
bibliotecas.
Para el lenguaje C, esto involucra
la forma en que se ubican las llaves,
se indenta el código y se utilizan los
paréntesis.

4. Importancia de Escribir Buen Código
Un código, aunque no siga las reglas de escritura, podrá funcionar,
pero es muy importante que personas, distintas a su autor, pueda
entenderlo; puesto que en muchas ocasiones, varios programadores
trabajan en un mismo proyecto de software, por lo cual cada uno debe
facilitar, tanto como sea posible, que los demás puedan comprender su
código.
Un código desordenado es difícil de leer y descifrar lo que éste
intenta hacer. Los programadores de un mismo proyecto deben ser
capaces de entender el código escrito por sus
compañeros, para así poder contribuir modificando,
reparando fallos y/o extendiéndolo en un período
breve de tiempo.
El código fuente es una forma de comunicación,
y debe ser un hábito de los programadores
escribir buenos código, de tal forma que sea fácil
de entender y modificar por otros.

5. Cualidades de un Buen Código
Limpieza: Un código limpio es fácil de leer; permite a las personas leerlo con
un mínimo esfuerzo y así pueden entenderlo más fácilmente.
 Consistencia: El código consistente permite más fácilmente que las
personas entiendan como funciona el programa; cuando se lee un código
consistente, sub-concientemente se forma un número de supuestos y
expectativas acerca del funcionamiento del código, de esta forma es más
fácil y seguro realizarle modificaciones.
 Extensibilidad: El código de propósito general es más fácil de reutilizar y
modificar que el código demasiado específico con muchos supuestos
escritos directamente en el código. Cuando alguien desea agregar una
nueva característica a un programa, obviamente será más fácil hacerlo si el
código fue diseñado para ser extensible desde el inicio. El código que no
fue escrito de esta forma hará que las personas deban implementar trucos
complicados para poder añadir características.
 Corrección: El código diseñado debe ser correcto para que las personas
pierdan menos tiempo preocupándose de los errores y se ocupen en
extender las características de un programa. Los usuarios también
apreciarán un código correcto, ya que a nadie le gusta que un programa se
caiga.

6. Reglas de Estilo de Programación
1. Modularizar un programa en subprogramas.
2. Evitar variables globales en subprogramas.
3. Usar nombres significativos para identificadores.
4. Definir constantes con nombres al principio del programa.
5. Evitar el uso del goto y no escribir nunca código spaghetti.
6. Uso adecuado de parámetros variable.
7. Uso adecuado de funciones.
8. Tratamiento de errores.
9. Legibilidad.
10. Documentación.

7. Reglas de Estilo de Programación
1. Modularizar un programa en subprogramas:
Un programa grande que resuelva un problema complejo siempre ha
de dividirse en módulos para ser más manejable.
Principales criterios para la modularización:
 Acoplamiento: Se trata del nivel de interdependencia entre
módulos. Es preciso minimizar la dependencia entre los módulos
de un programa. El grado de acoplamiento se puede utilizar para
evaluar la calidad de un diseño de sistema.
 Cohesión: Cada módulo debe ejecutar una sola
tarea con estricta relación de sus parte entre sí.
Mientras más fuerte sea esta relación más
cohesivo será el módulo.
Los módulos de un programa deben estar:
 Débilmente acoplados y
 Fuertemente cohesionados.

8. Reglas de Estilo de Programación
2. Evitar variables globales en subprogramas:
Una de las principales ventajas de los subprogramas es implementar
el concepto de un módulo aislado, pero esto se suprime cuando un
subprograma accede a variables globales, dado que los efectos de sus
acciones puede provocar efectos laterales en el programa.
El uso de variables globales con subprogramas no es correcto. Sin
embargo, el uso de la variable global en sí no tiene por qué ser
perjudicial. Así, si un dato es
inherentemente importante en un
programa que casi todo sub-
programa debe acceder al mismo,
entonces esos datos han de ser
globales por naturaleza.

9. Reglas de Estilo de Programación
3. Usar nombres significativos para identificadores:
Los identificadores que representan los nombres de módulos, subprogramas,
funciones, tipos, variables y otros elementos, deben ser elegidos apropiadamen-
te para conseguir programas legibles. El objetivo es usar nombres significativos
que ayuden a recordar el propósito de un identificador, sin tener que hacer refe-
rencia continua a declaraciones o listas externas de variables. Hay que evitar
abreviaturas crípticas.
Se deben utilizar identificadores largos para los objetos significativos de un
programa, como por ejemplo el nombre de un módulo usado frecuentemente.
Identificadores más cortos se utilizarán para objetos locales: i, j, k son útiles
para índices, contadores, etc., y son más expresivos que Indice, Contador, etc.
Los identificadores deben utilizar letras mayúsculas y minúsculas. Cuando un
identificador consta de dos o más palabras, cada palabra debe comenzar con
una letra mayúscula. Una excepción son los tipos de datos definidos por el usua-
rio, que suelen comenzar con una letra minúscula. Así identificadores idóneos
son: NombreEstudiante, SalarioMes, NumeroFactura, NotaFinal, etc., sin espa-
cios en blanco, ni empezando por un carácter numérico.

10. Reglas de Estilo de Programación
Los nombres de los identificadores deben sugerir su significado.
El estilo de escritura del código va a depender del programador, pero es
importante seguir las normativas, en la medida de lo posible, y ser consistente
en todo el programa.
4. Definir constantes con nombres al principio del programa:
Se deben evitar constantes explícitas siempre que sea posible. Por ejemplo,
no utilizar 7 para el día de la semana o 3.141592 para representar el valor de la
constante . En su lugar, es conveniente definir constantes con nombre, tal
como en lenguaje C:
#define Pi 3.141592
#define NumDiasSemana 7
#define Longitud 45
IDENTIFICADORES
Válidos No Válidos
numero
dia_del_mes
PIN1
CiudadNacimiento
i
123
_DÍA
numero*
lugar de nacimiento
año

11. Reglas de Estilo de Programación
5. Evitar el uso del goto y no escribir nunca código spaghetti:
Uno de los factores que más contribuyen a diseñar programas bien
estructurados es un flujo de control ordenado que implica los siguientes pasos:
1. El flujo general de un programa es adelante o directo.
2. La entrada a un módulo sólo se hace al principio y se sale sólo al final.
3. La condición para la terminación de bucles ha de ser clara y uniforme.
4. Los casos alternativos de sentencias condicionales han de ser claros y
uniformes.
El uso de una sentencia goto casi siempre viola al menos una de estas
condiciones. Además, es muy difícil verificar la exactitud de un programa que la
contenga. Por consiguiente, en general, se debe evitar su uso. Sin embargo,
existen situaciones en las que se necesita un flujo de control excepcional,
como cuando se requiere que un programa termine la ejecución por un error, o
bien porque un subprograma devuelve el control a su módulo llamador.
La inclusión de la sentencia en algunos lenguajes de compiladores
modernos como C# no implica para nada el uso de la sentencia goto y sólo en
circunstancias muy excepcionales, se debe recurrir a ella.

12. Reglas de Estilo de Programación
6. Uso adecuado de parámetros variable:
Un programa interactúa de un modo controlado con el resto del programa
mediante el uso de parámetros. Los parámetros valor pasan los valores al
subprograma, pero ningún cambio que hace a estos parámetros se refleja en
los parámetros reales de retorno a la rutina llamadora. La comunicación entre
la rutina llamadora y el subprograma es de un solo sentido; por esta causa, en
el caso de módulos aislados, se deben utilizar parámetros valor siempre que
sea posible.
Pero cuando se necesita devolver valores a la rutina llamadora, es adecuado
usar parámetros variable, ahora bien, si sólo se necesita devolver un único
valor, puede ser más adecuado usar una función.
Los parámetros variable, cuyos valores permanecen inalterables hacen el
programa más difícil de leer y más propenso a errores si se requieren
modificaciones; no obstante, pueden mejorar la eficiencia. La situación es
análoga a utilizar una constante en lugar de una variable cuyo valor nunca
cambia. Por consiguiente, se debe alcanzar un compromiso entre legibilidad y
modificabilidad por un lado y eficiencia por otro. A menos que exista una
diferencia significativa en eficiencia, se tomará generalmente el aspecto de la
legibilidad y modificabilidad.

13. Reglas de Estilo de Programación
7. Uso adecuado de funciones:
Una función se debe utilizar siempre que se necesite obtener un único
valor, por tanto no tiene un efecto lateral. Esto último sólo ocurriría
cuando las funciones usan variables globales o parámetros variables.
 Funciones con variables globales: Si una función referencia a una
variable global, presenta el peligro de un posible efecto lateral. En
general, las funciones no deben asignar valores a variables globales.
 Funciones con parámetros variable: Un parámetro variable es aquel
en que su valor cambiará dentro de la función. Este efecto es un
efecto lateral. En general, las funciones no deben utilizar parámetros
variables. Si se necesitan parámetros variables utilizar
procedimientos.

14. Reglas de Estilo de Programación
8. Tratamiento de errores:
Consiste en comprobar errores en las entradas y en su lógica e intentar
comportarse bien cuando los encuentra. Un subprograma debe comprobar ciertos
tipos de errores, tal como entradas no válidas o parámetros valor. Cuando se
detecta un fallo en un procedimiento, se debe presentar un mensaje de error y
devolver un indicador a la rutina llamadora para indicarle que ha encontrado una
línea de datos no válida; en este caso, el procedimiento deja la responsabilidad de
realizar la acción a la rutina llamadora. En otras ocasiones es más adecuado que
el propio subprograma tome las acciones pertinentes; por ejemplo, cuando la
acción requerida no depende del punto en que fue llamado el subprograma.
En el caso de un error fatal que invoque la terminación, una ejecución de
interrumpir puede ser el método más limpio para abortar. Otra situación delicada se
puede presentar cuando se encuentra un error fatal en estructuras condicionales
si-entonces-sino o repetitivas mientras, repetir. La primera acción puede ser llamar
a un procedimiento de diagnóstico que imprima la información necesaria para
determinar la causa del error; después de que el procedimiento ha presentado toda
esta información, se ha de terminar el programa. Sin embargo, si el procedimiento
de diagnóstico devuelve el control al punto en el que fue llamado, debe salir de
muchas capas de estructuras de control anidadas. En este caso la solución más
limpia es que la última sentencia del procedimiento de diagnóstico sea interrumpir.

15. Reglas de Estilo de Programación
9. Legibilidad:
Para facilitar la traza de un programa, este debe tener una buena
estructura y diseño, una buena elección de identificadores, buen
sangrado y utilizar líneas en blanco en lugares adecuados y una buena
documentación.
Elegir identificadores que describan fielmente su propósito, distinguir
entre palabras reservadas e identificadores definidos por el usuario.
Otra circunstancia importante a considerar es la indentación de las
diferentes líneas del mismo. Esto hace más comprensible y legible el
código, pues coloca los bloques de instrucciones con una sangría hacia
la derecha insertando espacios o tabuladores, para así separarlo del
margen izquierdo y distinguirlo mejor de las sentencias adyacente.

16. Reglas de Estilo de Programación
10. Documentación:
Es importante comunicar los detalles de un sistema, a través de la documentación.
Sin embargo, existe controversia entre los métodos tradicionales y los métodos ágiles
de desarrollo de software.
Por un lado las metodologías tradicionales hacen énfasis en que el producto software
debe tener un documento con todos los detalles que estén involucrados. Esto incluye
desde manuales extensos de usuario, hasta contratos entre la empresa desarrolladora
de software y el cliente que solicita el producto. Se debe aclarar que la documentación
resultante de estas metodologías es muy variada, puesto que está enfocada en mostrar
los detalles de diferentes puntos del sistema.
En contraste, las metodologías ágiles hacen énfasis en el hecho que al producir
software el enfoque debe ser orientado a los clientes, el usuario y los desarrolladores
mismos; considerando que la documentación no es tan importante, puesto que esta
tiende a degradarse y quedar obsoleta muy rápido con cada petición de cambio del
cliente. De este modo los desarrolladores deben atender al cliente, mostrando el
progreso y recibiendo retroalimentación constante por parte de estos. Los requerimien-
tos cambiantes no son un problema, puesto que existen diversos principios y estrate-
gias que se siguen para realizar los ajustes del cliente. Una de las debilidades de este
enfoque es que los desarrolladores tienden a no generar documentación ni de usuario,
ni de desarrolladores y muchas veces no suelen comentar el código fuente.

17. Generalidades
No existen reglas fijas para construir programas claros, comprensibles y
comprobables; pero hay guías generales que ayudan a estandarizar, en cierta
medida, los estilos de programación. No obstante, el estilo individual del
programador (o la ausencia de él), la claridad de su pensamiento (o la
oscuridad de él), su creatividad (o falta de ella), podrán contribuir
significativamente al éxito de esa tarea.
Es muy importante que un programador novato reconozca la importancia del
estilo en la práctica de su oficio y que desarrolle hábitos de estilo que le
permiten desenvolverse adecuadamente en su vida profesional, y exactamente
lo mismo a nivel grupal en un equipo de desarrollo. Así como un buen estilo de
escritura no se adquiere sólo a partir del conocimiento de las reglas de la
gramática, ningún buen estilo de programación puede adquirirse solamente a
partir del conocimiento de la sintaxis de algún lenguaje de programación.
La idea, que el formato y la apariencia del código fuente de un programa, no
son un incidente en su calidad, es errónea; puesto que es el formato el que
mejora la legibilidad del código.

18. Actividades
Investigar:
 Funcionabilidad y diferencias entre de variables globales y variables
locales.
 Los estilos para los nombres de identificadores (programas,
módulos, variables, etc.) y la indentación en lenguaje C –presente
ejemplos–
 La funcionabilidad, ventajas y desventajas de la instrucción goto.
 Definición, funcionabilidad y diferencias entre parámetros de valor y
parámetros variables.
 Realizar un cuadro comparativo entre Metodologías de desarrollo
software tradicionales y Metodologías de desarrollo ágiles: breve
descripción (haciendo énfasis en la documentación), semejanza,
diferencias, ventajas y desventajas.

19. Corona, M. y Ancona M. 2011. Diseño de algoritmos y su codificación
en lenguaje C. McGraw-Hill. México.
Joyanes, L. y Zahonero, I. 2002. Programación en C. Metodología,
algoritmos y estructura de datos. McGraw-Hill.
Joyanes, L. 2008. Fundamentos de Programación, Algoritmos,
Estructura de Datos y Objetos. Cuarta edición. McGraw-Hill.
López, J. Algoritmos y Programación. 2009. Segunda Edición. Eduteka.
Profa. Yenny Salazar
Referencias