Algunos errores frecuentes en las prácticas
En las entrevistas que hemos realizado durante la semana pasada ya los he ido comentando con vosotros individualmente, pero creo que puede ser provechoso para todos poner un pequeño resumen aquí. Se trata de errores que hemos podido ver en vuestro código; en muchos casos no perjudican la funcionalidad del programa, pero sí que afectan a todo lo que tiene que ver con la legibilidad y mantenibilidad del código (lo que pasaría si tenemos que volver a trabajar sobre el código de esta práctica un poco más adelante):
- Repetición de código:
- En muchos casos se ha desarrollado código para hacer las mismas cosas en distintos procedimientos y funciones. Por ejemplo, para desarrollar
quitar
del TAD multiconjunto es necesario buscar el elemento; también es necesario buscarlo para desarrollarpertenece
. También puede ser necesario (en algunas implementaciones del tipo, no en todas) para desarrollarponer
. Es una mala práctica copiar y pegar el mismo código (o prácticamente el mismo) en cada caso. - Ocurre algo parecido cuando se necesita añadir caracteres a una cadena. Por ejemplo en
getcad
, o enstr2cad
, donde lo natural sería utilizaraniadeCar
. - Unos pocos, además, han repetido el código a la hora de hacer
putcad
yputcad_line
, cuando claramente la segunda puede hacerse llamando a la primera. - Finalmente, parece que desconocíais la existencia de los descriptores de ficheros asociados a la entrada estándar (
Standard_Input
) y la salida estándar (Standard_Output
) que os hubieran permitido desarrollar las funciones de entrada y salida sin parámetro de fichero a partir de las otras
- En muchos casos se ha desarrollado código para hacer las mismas cosas en distintos procedimientos y funciones. Por ejemplo, para desarrollar
- ¡Cuidado con los límites!
- Sobre todo en implementaciones estáticas (tablas, vectores) hay que comprobar y tener en cuenta que la estructura de datos puede estar vacía (índice 0, ¿es posible?) o completamente llena (¿qué pasa cuándo queremos añadir un dato a una estructura en la que ya no caben más?).
- En estructuras dinámicas también hay que tener cuidado, en este caso con los punteros (el valor
NULL
del ‘siguiente’ del último dato indica el final de la lista). - Finalmente, algunos
getcad
de los que habéis desarrollado no contemplaban la posibilidad de que la cadena fuera vacía (el usuario le da al retorno de carro cuando estamos leyendo).
- Modificación de las especificaciones: Algunos grupos han evitado el problema de la lectura de cadenas del programa principal modificando la entrada esperada por el programa (normalmente, separando la cadena que se leía del carácter en líneas diferentes). Otros han modificado la especificación del programa para que tuviera que leer desde un fichero. Es mala idea hacer ese tipo de modificaciones porque a la hora de usar vuestro programa hay que ‘aprender’ su funcionamiento. Además, evitáis algunos de los problemas interesantes que planteaba la especificación original.