Uno de los errores que más se ha repetido es la separación de la condición de año bisiesto en dos condiciones if distintas. De esta manera se dificultad la comprensión del código ya que se espera que cada condición compruebe una única parte de la validación de la fecha.

En relación a esta última también ha sido habitual duplicar información dentro de las condiciones. Por ejemplo ha sido habitual encontrar código organizado del siguiente modo:

if ((fecha.anyo == enero) && (fecha.dia > 31)) {
    /* código */
} else if ((fecha.anyo == marzo) && (fecha.dia > 31)) {
    /* código */
}

cuando la condición que comprueba los meses de 31 días tendría que estar agrupada.

En algunos casos, no se ha incluido el else final en el ejercicio de comparación de fechas quedándose alguna de las posibilidades sin responder correctamente. Tal como os comenté en clase es importante incluir este else incluso cuando no sea necesario, ya que permite descubrir errores en el código que de otra manera pueden ser difíciles de detectar. Lo mismo se aplicara a la opción default del switch.

De nuevo han seguido apareciendo “números mágicos” en vez de constantes, sobre todo en los switch-case que en vez de utilizarse las constantes que representan a las opciones en los enumerados, se han empleado directamente los números. Las constantes permiten abstraer el código aportando significado a los números y facilitando la lectura. Así,

switch(opcion) {
...
    case nuevaSesion:
}

queda mas reconocible que hace esa parte del código que:

switch(d) {
...
    case 2:
}

(la d la he puesto a propósito ya que me he encontrado alguna combinación de este estilo)

Un error complicado de detectar es cuando se emplea el operador asignación en vez de la comparación dentro de un if

if (i = 5)

Lo tenéis explicado en un bocado de C.

Finalmente, recordar que a medida que el código se está haciendo cada vez más largo es fundamental que lo comentéis correctamente. Por un lado, aquellos símbolos que añadís de cosecha propia (constantes, variables, enumerados, estructuras…) son susceptibles de acompañarlos con un comentario, dado que son ajenos al que lee el código. Desde luego siempre es mejor un buen nombre que un buen comentario, pero no hay que desaprovechar la oportunidad de incluir información adicional cuando sea necesario. En especial en aquellas variables/constantes que sean claves para la comprensión del código. Por otro lado, los comentarios ayudan a seguir y comprender el flujo del programa, y a matizar porque se han tomado ciertas decisiones de programación. Ahora bien, tan importante es comentar el código como no pasarse comentando. Cada vez que se incluye un comentario de alguna manera se está introduciendo una duplicidad de información. Esto implica que a la hora de realizar cambios en el código puede que haya que tocar en dos sitios. Es fundamental que el comentario esté actualizado, sino confunde más que ayuda. En este sentido, hay que tener en consideración que el que lee vuestro código se supone que sabe C. Así que comentarios como los siguientes no tienen sentido a menos que estéis haciendo material docente:

printf("%s\n", name); /* imprimimos el nombre en una línea separada */
fclose(fd);  /* cerramos el fichero */