PT-BR/Guia do Desenvolvedor

Introdução

Então você decidiu virar um contribuidor do nosso projeto? Excelente! Mas antes que seu código possa ser enviado, é necessário o conhecimento de algumas sugestões e regras para evitar confusões entre nossos membros.

Code repository

Estrutura

Nosso code repository (SVN) é onde o código aberto do MTA é guardado. Sua especialidade é se lembrar de todas as mudanças feitas nos arquivos do programa, de modo que se uma falha o prejudica, é possível desfazer as alterações. Outra vantagem é a possibilidade de vários membros poderem contribuir pela internet.

Ele se divide em 3 diretórios, cada qual com sua função:

trunk: é o projeto mais recente, ainda em fase experimental

branches: aqui se encontram as ideias inovadoras, pesquisas interessantes e outros progressos, as quais não serão adicionados à raiz (trunk) em tão pouco tempo. As milestones, que prejudicam a estabilidade do programa, são um exemplo disso.

vendor: estão situadas aqui as livrarias e códigos de terceiros geralmente ligados ao nosso SVN. Eles podem ser acessados via comando "svn:externals"

Ganhando/Perdendo permissão de envio

O direito de continuar atualizando o código do MTA será concedido após aprovação, mostrando que você é competente. Isso para nós de extrema importância, porque o projeto é grande e não pode ser atrapalhado por problemas em códigos de baixa qualidade e discrepância entre os membros.

Patches podem ser enviados a nossa página de Bugs e Correções. Geralmente sua permissão à envios é cedida depois de 2 ou 3 correções, todavia isto não fixo e depende da disponibilidade dos contribuidores.

Se após ganho o acesso, seu código estiver consideravelmente ruim, ou não estiver seguindo às regras, a permissão será caçada e deverás novamente começar a enviar correções.

Casos à parte

Se você estiver interessado em trabalhar em algum complemento mais avançado, nós lhe daremos uma permissão especial no nível branch:

Isso significa que abriremos uma nova branch para seu trabalho, lhe garantindo exclusividade nela, mesmo se não tiveres subido nenhuma correção. Exemplos dos quais já foram implementados anteriormente são o Unicode e os comandos de voz, ambas vantagens de larga escala perante ao código.

É claro que terá de provar que és um bom programador ou fez algum considerável progresso no projeto até então. Inclusive seguir todas as regras de estilo de programação usado no MTA, uma vez que isso afetará toda a base do programa.

Se estiver interessado nisso, não hesite e contate-nos pelo IRC para abrir uma nova branch.

Enviando seu código

Lembrando que seus primeiros envios devem estar de acordo com nosso Bug tracker, ao corrigir ou adicionar alguma coisa. O nosso Roadmap está disponível justamente para os contribuidores eliminarem as principais pendências.

Por gentileza, não se esqueça de seguir as regras abaixo:

• Modificações enviadas ao trunk devem ser bem testadas. Aquelas que ainda precisam de revisão e afetem a estabilidade do programa, serão automaticamente desfeitas; salvo alguns casos excepcionais.
• Se estiver escrevendo algum código experimental ou instável, uma branch derá ser aberta para cada implementação. O que elas não podem é virar um espaço "pessoal" para cada usuário. Uma branch deve ser usada para novas coisas e como não um cantinho.
• As mensagens de log devem sempre citar de forma clara as mudanças realizadas, dispensando a visualização do código em si. Portando, inclua o número de protocolo do Mantis em sua mensagem de log e a faça legível. Exemplo: Fixed #1234: descrição e demais informações aqui. Se uma branch estiver relacionada, o nome dela deve ser colocada entre colchetes, como mostra o exemplo: [customanimations] Added IFP support.
• Caso alguma atualização for subida a um envio já realizado, inclua o número da anterior (de preferência do log) na sua. Feito isso, será mais fácil encontrar envios relacionados a fim de serem compilados mais tarde.

Avaliações e comentários

Essas duas ferramentas estão abertas ao público para revisar seu código e dar uma opinião. Por favor, seja adulto o suficiente quando for responder. Os desenvolvedores também irão avaliar quando for possível.

O que programar?

Geralmente o pessoal do MTA tenta seguir o Roadmap para programar alguma coisa. Esta página faz uma lista de pendências a serem resolvidas e implementadas na próxima versão. Claro, se você estiver interessado em algo diferente, tente uma vez e envie!

Estilo

• Use quatro espaços em vez de tabs.
• Use a notação húngara para as variáveis:

float         fValue;               // Variável local
unsigned char m_ucValue;            // Variável numérica Class member variable
char          ms_cValue;            // Variável estática Class static variable
bool          g_bCrashTwiceAnHour;  // Variável global
char*         szUsername;           // string terminada em zero
SString       strUsername;          // string
CVector       vecPosition;          // Vetor 3D

• Caixa baixa para definir as variáveis específicas como structs e enums customizadas:

SSomeStruct   valueOne;
ESomeEnum     m_valueTwo;

• Os nomes das funções SãoEmCaixaAlta:

void UpperCamelCase( void )

• Use um espaço entre quase tudo:

int iResult = 2 + 4 * GetValue() + 123;

• É opcional utilizar um espaço entre o nome da função e os parênteses:

void OkOne ( void )
void OkTwo( void )
OkThree ();
OkFour();

• Funções sem argumentos são declarados e definidos com ( void ) e chamados usando ()

void MyTest( void );
void MyTest( void ) { return; }
MyTest();

• Funções e variáveis relacionadas a classes/structs são alinhadas a colunas:

void       FunctionOne     ( void );
void       FunctionTwo     ( void );
float      fValue;

• Qualquer coisa a mais, simplesmente siga o estilo já usado atualmente.