Home

Regras gerais

1. Não serão aceitos Pull Requests sem uma descrição completa das alterações;

2. Não serão aceitos Pull Requests sem documentação no estilo Doxygen;

3. O código deverá ser escrito e documentado em Inglês (nomes de variáveis, interface, etc), podendo ter comentários em Português;

4. Não serão aceitos Pull Requests sem indentação correta e nomes fora do padrão do projeto (veja abaixo) ou ilegibilidades gerais;

5. Toda definição global em um código fonte (i.e. fora da definição de uma classe) deve ser feita dentro de um namespace para tal propósito. Utilize (ou crie) o namespace do módulo modificado e evite comandos como "using namespace ..." para não ocorrer conflitos de nomes;

6. Toda pesquisa e implementação de novas abordagens devem gerar estatísticas e um relatório deve ser feito com os resultados utilizando as métricas de desempenho cabíveis;

7. Branches não devem sobreviver a mais de 1 (sprint) e o número de alterações possíveis por Pull Request será limitado por bom senso;

8. Todo código presente num Pull Request será analisado detalhadamente e não será aceito caso não esteja em sua forma mais otimizada possível. Os nomes de variáveis também serão analisados e deverão balancear descritividade com tamanho dos mesmos.

9. Evite utilizar 'cout's. Existem métodos para Debug, como log, sucesso, aviso, erro e erro fatal. Para utilizá-los, leia a seção "Debugando".

Como rodar nosso código

1. Um único comando que verifica se todas as dependências estão instaladas, instala as que estiverem faltando, compila o projeto e o executa:

   sh run.sh

2. Para só instalar dependências e compilar o projeto:

   sh build.sh

3. ...ou, usando o make, digite:

   make

   para visualizar todas as opções de build e run disponíveis.

Padrões de nomeação

1. Todos os nomes devem ser em inglês;

2. Indentação deve ser feita com 4 espaços;

3. Nomes de classes devem respeitar o padrão CamelCase com a primeira letra maiúscula;

4. Nomes de métodos devem ter todas as letras minúsculas e diferentes palavras separadas por underline _;

5. Nomes de variáveis devem respeitar o padrão camelCase com a primeira letra minúscula.

6. Namespaces devem ter todas as letras maiúsculas e diferentes palavras separadas por underline _;

7. Constantes devem ter todas as letras maiúsculas sem separação de diferentes palavras;

8. Nomes de arquivos devem respeitar o padrão camelCase com a primeira letra minúscula;

9. Comentários gerais devem começar com letra minúscula e com um espaço depois do marcador de comentário (//, /*);

Padrões de indentação

1. Chaves são abertas na frente do bloco, sem linhas especiais para estas;

2. Não são acrescentadas linhas em branco entre abertura/fechamento de bloco e conteúdo;

3. Operações matemáticas e argumentos devem ter espaço entre os operandos;

4. Marcadores como case e public/private não devem adicionar recuo aos comandos seguintes;

5. Não devem ter espaços entre uma palavra chave e um parêntese;

6. Após um fechamento de parêntese, adicione um espaço;

Debugando

Como utilizar as funções de debug:

• Inclua o arquivo src/aux/debug.hpp antes da linha #ifndef (para que o compilador compartilhe os #define do arquivo de debug) e utilize alguma das funções abaixo.

Interface das funções:

• debug_log( string ): escreve uma linha de log normal (branca)
• debug_success( string ): escreve uma linha indicando sucesso numa operação (verde)
• debug_warning( string ): escreve uma linha avisando algo ocorrido (amarela)
• debug_error( string ): escreve uma linha de erro (vermelha)
• debug_fatal( string ): destaca uma linha quando ocorrer um erro fatal previsto (fundo vermelho)

---

Qualquer dúvida, consulte um administrador do projeto ou o Scrum Master.