En esta segunda parte de la práctica 2 los errores relacionados con la legibilidad del código que he encontrado son:

Comentarios

Es importante que el código esté correctamente comentado de cara al que vaya a leerlo. Cuando definimos una “palabra” nueva en el programa suele ser necesario que también incluyamos un comentarios con su significado. Esto ocurre cuando definimos una constante, por ejemplo. Las constantes tienen nombres asignados por nosotros que no tienen que coincidir con el nombre que definiría otro programador. Así, es básico ponerle un nombre que refleje claramente que representa la constante, y recomendable, también, añadir un comentario que ayude a explicar el significado. Un ejemplo lo podemos encontrar en la biblioteca math.h

#define MATH_ERRNO        1    /* errno set by math functions.  */

Dar formato a las estructuras

Cuando se define una estructura se lee más claro si los campos se encuentran sangrados a la derecha:

Incorrecto:

typedef struct {
int dia;
int mes;
int anyo;
}Fecha;

Correcto:

typedef struct {
    int dia;
    int mes;
    int anyo;
} Fecha;

Por otro lado, vamos a seguir el convenio de nombrar los nuevos tipos de datos que definamos con la primera en mayúscula. Así definimos Fecha en vez de fecha.

Castellano o inglés

A la hora de decidir las nuevas “palabras” de vuestro programa (nombres de constantes y de variables, por el momento) es preciso mantener coherencia en el idioma que se utiliza. No mezclarlos.

Inicializar las variables

En el último ejercicio el campo numSesion contabilizaba el número de usuarios válidos que se había introducido. Este campo es preciso inicializarlo a cero para que al incrementarlo funcione correctamente en todas las plataformas. Algunos veces puede que las variables no inicializadas se le asigne el valor 0, pero no podemos confiar en que esa así.