Boas práticas

• Não se replica código por razões óbvias de boas práticas.
• Uma função ou ficheiro replicado implica muito mais trabalho ou inconsistência porque nem todas as cópias são alteradas.
• A maioria das vossas função estão a aceder diretamente aos dados. Isto não pode acontecer.
• É necessário criar uma independência entre os dados e o resto do código.
• Isto implica criar getters e setters para cada um dos campos da estrutura.
• É necessário dividir o código em três camadas: dados, lógica e interface
• Todas as funções da lógica do programa não mexem na estrutura de dados diretamente, só através dos getters e dos setters
• Nenhuma das funções da lógica do programa nem da camada de dados fazem interface com o utilizador (e.g., scanfs, printfs)
• Todo o interface com o utilizador é feito na camada de interface
• A camada de interface utiliza as funções da lógica do programa, não deveria sequer utilizar os getters e os setters
• Deverão ser criadas funções auxiliares com nomes sugestivos para ajudar a estruturar o programa
• Não escrever código repetitivo que implica o uso de copy&paste, em vez disso usar funções auxiliares/ciclos para diminuir esse tipo de trabalho o máximo possível

Comentários depois da avaliação

Seguem-se alguns dos comentários comuns a várias submissões do guião 5.

Genéricamente, os grupos que submeteram fizeram um bom trabalho. Contudo, encontrámos alguns problemas, nomeadamente:

• Projetos submetidos várias vezes
• Includes mal feitos
• Falta de independência entre as camadas

Projetos submetidos várias vezes

Parece-me que há grupos a criarem um projeto github por elemento e a submetê-los em separado.

Pretende-se que cada grupo crie um só projeto github. Podem e devem existir commits de mais do que um dos elementos do grupo visto que não é suposto que só um dos elementos do grupo trabalhe. # Includes mal feitos

Houve grupos a escreverem:

#include "./meu_ficheiro.h"

Quando deveriam escrever:

#include "meu_ficheiro.h"

Falta de independência entre as camadas

Este é um problema mais comum:

• Funções da camada da lógica do programa a aceder diretamente aos dados
• Funções da camada da interface a aceder diretamente aos dados

Segue-se um exemplo:

void mostrar_tabuleiro(ESTADO *e) {
    for (int i = 0; i < 8; i++) {
        for (int k = 0; k < 8; k++) {
            if (i == 0 && k == 7)
                printf("2");
            else if (i == 7 && k == 0)
                printf("1");
            else
                printf((e->tab[i][k] == VAZIO) ? "." : (e->tab[i][k] == BRANCA) ? "*" : "#" );
        }
        putchar('\n');
    }
}

O problema deste caso é que agora se eu decidir mudar a estrutura dos dados vou ter que mudar esta função. Mas se a função fosse:

void mostrar_tabuleiro(ESTADO *e) {
    for (int i = 0; i < 8; i++) {
        for (int k = 0; k < 8; k++) {
            if (i == 0 && k == 7)
                printf("2");
            else if (i == 7 && k == 0)
                printf("1");
            else
                printf(obter_casa(e, i, k) == VAZIO) ? "." : (obter_casa(e, i, k) == BRANCA) ? "*" : "#" );
        }
        putchar('\n');
    }
}

Então uma mudanças à estrutura dos dados já não obriga a mexer na função mostrar_tabuleiro.

O mesmo aconteceu frequentemente na função jogar que pertence à logica do programa.