Introducción a la calidad de código

Transcripción

1 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

2 Índice 1. Introducción 2 2. Qué es la calidad de software? 2 3. Calidad de Código Legibilidad del código Nombres de variables Nombres de funciones/procedimientos Cantidad de parámetros Comentarios en el código 5 Autor: Bernardo Ortega Moncada 1

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

4 3. 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 Program notas alum ; 2 Uses c r t ; 3 Const ALUM=10; 4 Type tvector = array [ 1..ALUM] o f i n t e g e r ; 5 Var Notas : tvector ; 6 Procedure toma datos ( var v e c t o r : tvector ) ; 7 Var i : i n t e g e r ; 8 Begin 9 For i :=1 to ALUM do 10 Begin 11 Writeln ( I n g r e s e l a nota d e l alumno, i, de l a l i s t a ) ; 12 Readln ( v e c t o r [ i ] ) ; 13 End ; 14 Writeln ( Carga de datos f i n a l i z a d a ) ; 15 End ; 16 Procedure muestra datos ( var v e c t o r : tvector ) ; 17 Var i : i n t e g e r ; 18 Begin 19 Writeln ( Notas de l o s alumnos : ) ; 20 For i :=1 to ALUM do 21 Writeln ( i : 3, :, v e c t o r [ i ] ) ; 22 End ; 23 Begin 24 C l r s c r ; 25 toma datos ( Notas ) ; 26 w r i t e l n ; 27 muestra datos ( Notas ) ; 28 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 Program notas alum ; 2 Uses c r t ; 3 Const ALUM=10; 4 Type tvector = array [ 1..ALUM] o f i n t e g e r ; 5 Var Notas : tvector ; 6 7 Procedure toma datos ( var v e c t o r : tvector ) ; 8 Var i : i n t e g e r ; 9 Begin 10 For i :=1 to ALUM do 11 Begin 12 Writeln ( I n g r e s e l a nota d e l alumno, i, de l a l i s t a ) ; 13 Readln ( v e c t o r [ i ] ) ; 14 End ; 15 Writeln ( Carga de datos f i n a l i z a d a ) ; 16 End ; Procedure muestra datos ( var v e c t o r : tvector ) ; 19 Var i : i n t e g e r ; Autor: Bernardo Ortega Moncada 3

5 20 Begin 21 Writeln ( Notas de l o s alumnos : ) ; 22 For i :=1 to ALUM do 23 Writeln ( i : 3, :, v e c t o r [ i ] ) ; 24 End ; Begin {Programa P r i n c i p a l } 27 C l r s c r ; 28 toma datos ( Notas ) ; 29 w r i t e l n ; 30 muestra datos ( Notas ) ; 31 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 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: 2 lpp : I n t e g e r ; 3 d i s t a n c i a : Real ; 4 Total1 : Long ; 5 Total2 : Byte ; Codigo2: Malos nombres de variables 2 l i n e a s p o r p a g i n a : I n t e g e r ; 3 Distancia En Metros : Real ; 4 Maximo : Long ; 5 Minimo : Byte ; Codigo2: Buenos Nombres de variables 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 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: 2 No Encontrado : Boolean ; 3 No Error : Boolean ; 4 No Terminado : Boolean ; 5 Sexo : Boolean ; Codigo4: Malos Nombres para variables booleanas Autor: Bernardo Ortega Moncada 4

6 3.3. 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 Function buscareliminar ( p o s i c i o n : I n t e g e r ) : I n t e g e r ; 2 Procedure findempleadodelete ( p o s i c i o n : I n t e g e r ) ; 3 Procedure bee ( ) ; 4 Procedure buscempel ( ) ; Codigo5: Buenos Nombres para funciones/procedimientos 1 Function busquedarapida ( p o s i c i o n : I n t e g e r ) : I n t e g e r ; 2 Procedure eliminarempleado ( p o s i c i o n : I n t e g e r ) ; 3 Function obtenersaldo ( unacuentabancaria : tr CuentaBancaria ) : Real ; 4 Function obtenerpromedio ( unvector : t a V e c t o r ) : Real ; 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 asigno 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