Convenciones

Introducción

En general no programamos aislados en el vacío. Otras personas necesitan leer código que escribimos, en este caso los profesores, pero en una empresa o proyecto nuestros pares. En un proyecto opensource incluso mucha gente que ní siquiera conocemos.

A su vez esto es recíproco, es decir, nosotros también necesitamos ver e incluso modificar código hecho por otras personas.

Con lo cual es escencial adoptar buenas prácticas para estructurar el código y expresarlo de forma legible y entendible de la manera más rápida posible.

Es decir que cualquiera pueda ver una función o un conjunto de funciones y solo concentrarse en entender la lógica de lo que hace, y no marearse con temas de sintaxis, o nomenclatura.

Entonces nosotros vamos a adoptar varias convenciones de trabajo para esto, que enumeramos acá.

Es importante seguirlas en los TP's.

Separación entre Aplicaciones y Pruebas y librerías principales

Nuestros TP's en general tendrán dos partes:

• La lógica en sí del dominio (negocio), por ejemplo las ideas de Producto, Factura, Item, precios, etc. junto a todas las funciones que me permiten operarlas (los TDA's), por ejemplo calcular el total de una factura, obtener el promedio de consumo mensual de clientes, etc, etc.
  • Clases / Structs
  • Funciones
• Una Aplicación de ejemplo que usa ese dominio con datos concretos.
• TestCases si existieran (al principio de la materia no vemos este tema)

Es muy importante mantener una separación entre estas tres cosas. A fin de cuenta el componente más importante de nuestro trabajo es el primero, porque al ser genérico yo lo podría utilizar para distintos programas con distintos datos.

Operaciones de Entrada/Salida (consola)

En general no vamos a pedir que codifiquen comportamiendo con entrada/salida. Porque suele desviar nuestra atención en aspectos más importantes para perder tiempo con problemas de consola.

Sin embargo, si quieren pueden jugar con estas operaciones.

Lo que es realmente importante es no incluir la lógica de consola dentro de las operaciones del TDA.

Convenciones de Nombres

CamelCase es una convención muy utilizada para nombras variables o tipos.

La idea es cuando tengo una expresión de más de una palabra por ejemplo "cuenta corriente actual", e igualmente necesito escribir una única palabra en código, escribo todo junto, pero con un caracter en mayúscula para distinguir donde comienza cada palabra de la original

cuenta corriente actual    ->  cuentaCorrienteActual

Vamos a usar bastante esta convención.

Formateo de Código

El código DEBE estar formateado ! Es decir indentado !

Prestar atención al hecho de tener lineas indentadas a diferentes niveles. Dificulta la lectura del código !

Una buena práctica es ejecutar el formateador de código del eclipse bastante seguido CTRL+SHIFT+F (Pueden recordar "F" de Formatear).

Por ejemplo, en lugar de un código así:

struct Mundo* crearMundo(char nombreMundo[40]){

struct Mundo* punteroMundo;

strcpy(punteroMundo->mundoName,nombreMundo);

    punteroMundo =(struct Mundo*)malloc(sizeof(struct Mundo));

    punteroMundo->cantNiveles=0;

    punteroMundo->punteroNivel=NULL;

return punteroMundo;

}

Debería ser:

struct Mundo* crearMundo(char nombreMundo[40]){

    struct Mundo* punteroMundo;

    strcpy(punteroMundo->mundoName,nombreMundo);

    punteroMundo =(struct Mundo*)malloc(sizeof(struct Mundo));

    punteroMundo->cantNiveles=0;

    punteroMundo->punteroNivel=NULL;

    return punteroMundo;

}

Utilizamos además, la convención de la apertura de llaves en la misma linea, y el cierre en una linea nueva.

Ejemplo, en lugar de esto:

if (puedeJugar(jugador)

{

    jugar(jugador);

}

Usamos:

if (puedeJugar(jugador){

    jugar(jugador);

}