Buenas prácticas de programación

We will never be rid of code, because code represents the

details of the requirements. At some level those details
cannot be ignored or abstracted; they have to be
Buenas prácticas de programación specified. And specifying requirements in such detail that
a machine can execute them is programming. Such a
specification is code.
(...) code is really the language in which we ultimately
express the requirements. We may create languages that
Algoritmos y Estructuras de Datos I are closer to the requirements. We may create tools that
help us parse and assemble those requirements into
formal structures. But we will never eliminate necessary
precision –so there will always be code.
Robert Martin, 2009.

Buenas prácticas de programación Utilizar nombres declarativos

I know of one company that, in the late 80s, wrote a I Usar nombres que revelen la intención de los elementos
killer app. It was very popular, and lots of professionals nombrados. El nombre de una variable/función deberı́a decir
bought and used it. But then the release cycles began to todo lo que hay que saber sobre la variable/función!
stretch. Bugs were not repaired from one release to the
1. Los nombres deben referirse a conceptos del dominio del
next. Load times grew and crashes increased (...) The
problema.
company went out of business a short time after that. 2. Una excepción suelen ser las variables con scopes pequeños. Es
Two decades later I met one of the early employees of habitual usar i, j y k para las variables de control de los ciclos.
that company and asked him what had happened. The 3. Si es complicado decidirse por un nombre o un nombre no
parece natural, quizás es porque esa variable o función no
answer confirmed my fears. They had rushed the product
representa un concepto claro del problema a resolver.
to market and had made a huge mess in the code. As
they added more and more features, the code got worse I Evitar la desinformación!
and worse until they simply could not manage it any
1. Llamar hp a la “hipotenusa” es una mala idea.
longer. It was the bad code that brought the company
2. Tener variables llamadas
down. cantidadDeElementosEnElEjeXSinMarcar y
Robert Martin, 2009. cantidadDeElementosEnElEjeYSinMarcar no es buena idea.
Utilizar nombres declarativos Utilizar nombres declarativos

1 int x = 0;
I Usar nombres pronunciables! No es buena idea tener una 2 vector<double> y;
variable llamada cdcptdc para representar la “cantidad de 3 ...
cuentas por tipo de cliente”. 4 for(int i=0;i<=4;i=i+1) {
5 x = x + y[i];
I Se debe tener un nombre por concepto. No tener funciones 6 }
llamadas grabar, guardar y registrar.
1 int totalAdeudado = 0;
I Los nombres de las funciones deben representar el concepto
2 vector<double> deudas;
calculado, o la acción realizada en el caso de las funciones 3 ...
void. 4 for(int i=0;i<=4;i=i+1) {
5 totalAdeudado = totalAdeudado + deudas[i];
I No hacer chistes! 6 }

Utilizar nombres declarativos Indentación (sangrado)

1 int main () {
2 int i, j;
3 for (i = 0; i <= 10; i++){
1 4 for (j = 0; j <= 10; j++){
2 int x = aux1(); 5 cout << i << ” x ” << j << ” = ” << i∗j;
3 int y = aux2(); 6 }
4 int z = x / y; 7 }
5 return z; 8 return 0;
9 }

1 1 int main () {
2 int cantidadPaisesLatinos = obtenerTotalPaisesLatinos(); 2 int i, j;
3 int totalDePaises = obtenerTotalDePaises(); 3 for (i = 0; i <= 10; i++){
4 int promedio = cantidadPaisesLatinos / totalDePaises; 4 for (j = 0; j <= 10; j++){
5 return promedio; 5 cout << i << ” x ” << j << ” = ” << i∗j;
6 }
7 }
8 return 0;
9 }
Comentarios Comentarios

I Los comentarios no arreglan código de mala calidad! En lugar

I Además de escribir comandos, los lenguajes de programación
de comentar el código, hay que clarificarlo.
permiten escribir comentarios.
I Tipos de comentarios en C++:
I Es importante expresar las ideas en el código, y no en los
comentarios.
I Comentario de lı́nea: // ...
I Comentario de bloque: /* ... */ I Los mejores comentarios son los conceptos que no se pueden
escribir en el lenguaje de programación utilizado:
I Es importante hacer un uso adecuado de los comentarios, para 1. Explicar la intención del programador.
que no oscurezcan el código. 2. Explicitar precondiciones o suposiciones.
3. Clarificar código que a primera vista puede no ser claro.

Comentarios: Malos usos Comentarios: Buenos usos

I Ejemplo 1:
I Ejemplo 1:
1 /∗∗
1 /∗∗ 2 ∗ Computa el mı̈¿ 12 dulo del vector de a partir de dos coordenadas.
2 ∗ Funciı̈¿ 21 n que toma dos enteros y devuelve un float. 3 ∗ Las coordenadas deben ser nı̈¿ 12 meros no negativos.
3 ∗/ 4 ∗ Si la precondiciı̈¿ 12 n no se cumple, retorna −1.
4 float calculateModule(int x, int y) {...} 5 ∗/
6 float calculateModule(int x, int y) {...}
I Ejemplo 2:
1 while (x<y) { // itero hasta que x es mayor o igual que y
I Ejemplo 2:
2 ... 1 // almacena los Ids de los clientes que compraron productos
3 } 2 vector<s> clientIds;

I Ejemplo 3: I Ejemplo 3:
1 cout << y; // Imprimo el valor de y 1 // el llamado a f se hace siempre con y>0
2 x = f(y);
Variables: Inicialización Variables: Scope de declaración
I Usar el scope más pequeño posible!
I Ejemplo: Definición fuera de scope más pequeño posible:
I En C/C++ podemos tener variables declaradas pero no
inicializadas, y el valor que contienen en ese caso es 1 int main() { // scope 1
impredecible (decimos que contienen “basura”). 2 int t = 0;
3 while (...) { // scope 2
I Para evitar esta situación, es recomendable inicializar siempre 4 while (...) { // scope 3
las variables. 5 t = ...
6 }
I Falta inicializar: 7 }
1 int i;
2 i = 10; // mal I Ejemplo: Definición en scope más pequeño posible:
1 int main() { // scope 1
I Bien inicializado: 2 while (...) { // scope 2
1 int i = 10; // bien 3 while (...) { // scope 3
4 int t = ...
5 }
6 }

Funciones Formato vertical

I Los archivos del proyecto no deben ser demasiado grandes!

I Las funciones deben ser pequeñas! Una función con
demasiado código es difı́cil de entender y mantener. I Conceptos relacionados deben aparecer verticalmente cerca en
los archivos.
1. Encapsular comportamiento dentro de funciones auxiliares!
I Las funciones más importantes deben estar en la parte
I Regla fundamental. Cada función debe ... superior, seguidas de las funciones auxiliares.
1. ... hacer sólo una cosa,
2. ... hacerla bien, y 1. Siempre la función llamada debe estar debajo de la función
3. ... ser el único componente del programa encargado de esa llamadora.
tarea particular. 2. Las funciones menos importantes deben estar en la parte
inferior del archivo.
I Las funciones no deben tener efectos colaterales! En
particular, el uso de variables globales debe ser
I Se suele equiparar un archivo de código con un artı́culo
particularmente cuidado. periodı́stico. Debemos poder interrumpir la lectura en
cualquier momento, teniendo información acorde con la
lectura realizada.
Modularización Modularización

I Cada archivo del proyecto debe tener código homogéneo, y

I Single responsibility principle: Cada función debe tener un
único motivo de cambio.
relacionado con un concepto o grupo de conceptos
coherentes. 1. Interfaz de usuario.
2. Tecnologı́a para la interfaz de usuario.
I Los nombres de los archivos también deben ser 3. Lógica de negocio.
representativos! 4. Consideraciones sobre los algoritmos.
5. Almacenamiento permanente.
I Muchos lenguajes de programación dan facilidades para 6. ...
organizar archivos en paquetes (o conceptos similares), para
tener una organización en más de un nivel. I El código responsable de cada uno de estos aspectos debe
estar separado del resto!

Bibliografı́a

I Robert Martin, Clean code. Prentice-Hall, 2009.

I Steve McConnell, Code complete. Microsoft Press, 1993.