Introducción a la calidad de código

Universidad de Buenos Aires
Facultad De Ingenierı́a
Introducción a la calidad de código
[75.40] Algoritmos y Programación I
2do Cuatrimestre 2010
Cátedra: Ing. Pablo Guarna
Autor: Bernardo Ortega Moncada
Apunte de Calidad de Código
2do Cuatrimestre 2010
Índice
1. Introducción
2
2. ¿Qué es la calidad de software?
2
3. Calidad de Código
3.1. Legibilidad del código . . . . . . . . .
3.2. Nombres de variables . . . . . . . . . .
3.3. Nombres de funciones/procedimientos
3.3.1. Cantidad de parámetros . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
3
4
5
5
4. Comentarios en el código
5
Autor: Bernardo Ortega Moncada
1
Apunte de Calidad de Código
1.
2do Cuatrimestre 2010
Introducción
Este documento está orientado para que los alumnos de [75.40] Algoritmos y Programación I, Cátedra: Ing.
Pablo Guarna, comprendan el concepto de la calidad del código al momento de diseñar un software.
Lo cual les permitirá generar códigos con mayor claridad, mas eficientes y mas adaptados para una futura mejora.
2.
¿Qué es la calidad de software?
Quizás uno puede estar pensando que la calidad de el software es prácticamente el desempeño del mismo al momento
de resolver cierto problema, o quizás la interfaz que tiene con el usuario. Si bien estos dos conceptos son correctos para
definir la calidad de software, no quiere decir que sean los únicos.
Existen otros factores que definen la calidad de software. Estos factores son:
Confiabilidad
Facilidad de uso
Seguridad
Funcionalidad
Oportunidad
Costo
Eficiencia en el desempeño
Interoperabilidad
Extensibilidad
Reutilización
Portabilidad
Escalabilidad
En este documento no me voy a centrar en explicar todos los conceptos de calidad de software, sino mas bien me voy
a centrar en la calidad de el código de un software.
Antes que nada quiero dejarles citado una frase: ((El código es el único artefacto del desarrollo de software que siempre
se va a construir))1
1 Ing.
Carlos Fontela. Profesor de las materias [75.07] Algoritmos y Programación III y [75.47] Taller de Desarrollo de Proyectos II
Autor: Bernardo Ortega Moncada
2
Apunte de Calidad de Código
3.
2do Cuatrimestre 2010
Calidad de Código
Vamos a ver algunos puntos importantes para la calidad de código
3.1.
Legibilidad del código
La legibilidad del código es sumamente importante, ya que esto nos facilita en la búsqueda de errores del mismo y
una posible refactorización (o mejora).
Veamos el siguiente ejemplo:
Codigo1: Ingreso de notas a 10 alumnos
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
Program n o t a s a l u m ;
Uses c r t ;
Const ALUM=10;
Type t V e c t o r = a r r a y [ 1 . .ALUM] o f i n t e g e r ;
Var Notas : t V e c t o r ;
P r o c e d u r e t o m a d a to s ( var v e c t o r : t V e c t o r ) ;
Var i : i n t e g e r ;
Begin
For i :=1 t o ALUM do
Begin
W r i t e l n ( ’ I n g r e s e l a nota d e l alumno ’ , i , ’ de l a l i s t a ’ ) ;
Readln ( v e c t o r [ i ] ) ;
End ;
W r i t e l n ( ’ Carga de d a t o s f i n a l i z a d a ’ ) ;
End ;
P r o c e d u r e m u e s t r a d a t o s ( var v e c t o r : t V e c t o r ) ;
Var i : i n t e g e r ;
Begin
W r i t e l n ( ’ Notas de l o s alumnos : ’ ) ;
For i :=1 t o ALUM do
Writeln ( i : 3 , ’ : ’ , vector [ i ] ) ;
End ;
Begin
Clrscr ;
to m a d a t o s ( Notas ) ;
writeln ;
m u e s t r a d a t o s ( Notas ) ;
End .
Podemos apreciar que es muy desprolijo y ademas es muy poco claro, lo cual le quita legibilidad al mismo.
Ahora veamos el mismo código, pero utilizando la tabulación correspondiente:
Codigo1: Ingreso de notas a 10 alumnos
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Program n o t a s a l u m ;
Uses c r t ;
Const ALUM=10;
Type t V e c t o r = a r r a y [ 1 . .ALUM] o f i n t e g e r ;
Var Notas : t V e c t o r ;
P r o c e d u r e t o m a d a to s ( var v e c t o r : t V e c t o r ) ;
Var i : i n t e g e r ;
Begin
For i :=1 t o ALUM do
Begin
W r i t e l n ( ’ I n g r e s e l a nota d e l alumno ’ , i , ’ de l a l i s t a ’ ) ;
Readln ( v e c t o r [ i ] ) ;
End ;
W r i t e l n ( ’ Carga de d a t o s f i n a l i z a d a ’ ) ;
End ;
P r o c e d u r e m u e s t r a d a t o s ( var v e c t o r : t V e c t o r ) ;
Var i : i n t e g e r ;
Autor: Bernardo Ortega Moncada
3
Apunte de Calidad de Código
20
21
22
23
24
25
26
27
28
29
30
31
2do Cuatrimestre 2010
Begin
W r i t e l n ( ’ Notas de l o s alumnos : ’ ) ;
For i :=1 t o ALUM do
Writeln ( i : 3 , ’ : ’ , vector [ i ] ) ;
End ;
Begin { Programa P r i n c i p a l }
Clrscr ;
t o m a d a to s ( Notas ) ;
writeln ;
m u e s t r a d a t o s ( Notas ) ;
End .
Se puede apreciar que el último código es muchı́simo mas claro y muchı́simo mas fácil para realizar un seguimiento en
el caso de una mejora.
Tengan en mente esto siempre: El código se escribe una vez y se lee muchas veces.
3.2.
Nombres de variables
Los nombres de las variables tienen que ser claros y entendibles, ya que los mismos son utilizados para realizar infinitas
operaciones. Pasemos a mostrar un ejemplo de lo que se dice:
Codigo2: Malos nombres de variables
1
2
3
4
5
Var
lpp : I n t e g e r ;
d i s t a n c i a : Real ;
T o t a l 1 : Long ;
T o t a l 2 : Byte ;
Codigo2: Buenos Nombres de variables
1 Var
2 lineas por pagina : Integer ;
3 D i s t a n c i a E n M e t r o s : Real ;
4 Maximo : Long ;
5 Minimo : Byte ;
Existe la excepción a las variables de iteración en los ciclos: For, While y Repeat Until, como por ejemplo:
Codigo3: Buenos Nombres de variables para iteración
1 Var
2 i , j , k : I n t e g e r ; { v a r i a b l e s de i t e r a c i ó n para v a r i o s c i c l o s }
También hay un standard para las variables booleanas, por ejemplo, si sabemos que las variables booleanas solo
pueden almacenar 2 valores distintos True y False. Entonces el standard para elegir el nombre en una variable booleana
es no darles un nombre negativo, o nombres pocos claros, ya que los mismos pueden prestar confusión al momento de la
codificación. Veamos un ejemplo:
Codigo4: Malos Nombres para variables booleanas
1
2
3
4
5
Var
No Encontrado : Boolean ;
No Error : Boolean ;
No Terminado : Boolean ;
Sexo : Boolean ;
Autor: Bernardo Ortega Moncada
4
Apunte de Calidad de Código
3.3.
2do Cuatrimestre 2010
Nombres de funciones/procedimientos
Los nombres de las funciones/procedimientos son muy importantes, ya que el mismo siempre describe que es lo que
hace dicha función/procedimiento, pero de una forma tal, que sólo expresa la intención (o el qué) y no detalles de implementación (el cómo). Otro buen punto es no mezclar idiomas en los nombres de las funciones/procedimientos, es decir,
mezclar el inglés con el español.
Veamos algunos ejemplos de malos nombres para funciones/procedimientos:
Codigo5: Malos Nombres para funciones/procedimientos
1
2
3
4
Funct ion b u s c a r E l i m i n a r ( p o s i c i o n : I n t e g e r ) : I n t e g e r ;
Procedure findEmpleadoDelete ( p o s i c i o n : I n t e g e r ) ;
P r o c e d u r e bee ( ) ;
P r o c e d u r e buscEmpEl ( ) ;
Codigo5: Buenos Nombres para funciones/procedimientos
1
2
3
4
Funct ion busquedaRapida ( p o s i c i o n : I n t e g e r ) : I n t e g e r ;
Procedure eliminarEmpleado ( p o s i c i o n : I n t e g e r ) ;
Funct ion o b t e n e r S a l d o ( unaCuentaBancaria : t r C u e n t a B a n c a r i a ) : Real ;
Funct ion obtenerPromedio ( unVector : t a V e c t o r ) : Real ;
3.3.1.
Cantidad de parámetros
La cantidad de parámetros en las funciones/procedimientos tiene que ser como máximo 7, ya que quedó demostrado
que al haber demasiados parámetros se presta a la confusión al momento de codificar dicha función/procedimiento y
ademas es una muestra de la falla de modularización del programa
4.
Comentarios en el código
Los comentarios en el código son de vital importancia, al momento de explicar ciertas partes del código que creemos
que es necesario explicar. Pero no todo es color de rosa en la vida de un informático, si bien los comentarios sirven para
explicar lineas, también son un arma de doble filo, ya que un código extremadamente comentado, significa que dicho código
es extremadamente complejo de entender y que su diseño es extremadamente retorcido. Lo cual implica una revisión y
un re-diseño del mismo.
NUNCA se debe comentar lo obvio, es decir repetir en el comentario lo que se dice en el código, como por ejemplo:
Codigo6: Mal uso de los comentarios
1 VAR
2
edad : I n t e g e r ;
3
4 BEGIN { Cuerpo P r i n c i p a l d e l programa }
5
{Le a s i g n o e l v a l o r 21 a l a v a r i a b l e edad }
6
edad := 21
7 END.
Autor: Bernardo Ortega Moncada
5