Clone do famoso jogo como um projeto de Laboratórios de Informática I

See screenshots for more images.

• Humberto Gil Azevedo Sampaio Gomes (a104348[at]alunos.uminho.pt)
• José António Fernandes Alves Lopes (a104541[at]alunos.uminho.pt)

20 / 20 ⭐

Com SSH:

$ git clone [email protected]:uminho-di/li1/2223/projetos/2022li1g012.git

Ou por HTTPS:

$ git clone https://gitlab.com/uminho-di/li1/2223/projetos/2022li1g012.git

Uma dependência opcional para jogar com áudio é o mpv.

Para correr o programa (compilação automática do projeto e das dependências):

$ cabal run exe:2022li1g012

Para instalar o jogo:

$ cabal install

Para testar funções durante o processo de desenvolvimento, o ghci é iniciado com:

$ cabal repl exe:2022li1g012

O projeto utiliza a biblioteca HUnit para fazer testes unitários. Para os executar:

$ cabal test

Pode gerar a documentação do projeto usando Haddock:

$ cabal haddock --haddock-all

Seguem-se algumas normas na escrita de código para garantir a sua uniformidade. Estas são vagamente inspiradas nas orientações recomendadas para Haskell.

• As linhas devem ter, no máximo, um comprimento de 80 caracteres;

• Não deixar espaço em branco numa linha vazia ou no final de uma linha (trailing whitespace);

• Não usar tabulações. Dois espaços devem ser usados no seu lugar;

• Um ficheiro deve terminar com o caracter newline ('\n', 0x0A);

• Em guardas e casos envolvendo where, let, do e case, deve começar-se uma nova linha para as novas expressões, que se devem manter alinhadas;

fact n
  | n == 0 = 1
  | n > 0  = n * fact (n - 1)

• Notação de expressões lambda: preferir \ x -> ... a \x -> ...;

• Usar um espaço para separar as parcelas de operadores (foo == bar).

• Utilizar camelCase para funções e PascalCase para tipos, módulos, ...

• Funções com acumulador devem ter o nome da função principal com o sufixo Acc. Exemplo:

sum lst = sumAcc lst 0
  where sumAcc []     acc = acc
        sumAcc (x:xs) acc = sumAcc xs (x+acc)

• O nome das funções, dos tipos de dados e de variáveis devem estar em língua portuguesa;

• Explicitar o tipo de funções;

• Evitar funções parciais (por exemplo, usando o tipo Data.Maybe);

• Procurar escrever funções sucintas e reutilizáveis para outros problemas;

• Documentar o código com o Haddock e procurar escrever testes unitários com HUnit.