• Nenhum resultado encontrado

com redundância implementada AvailableD

4. Padrões de Codificação

A fim de manter um código legível e de fácil manutenção, faz-se necessário determinação de alguns padrões norteadores do desenvolvimento de código. A seguir, são apresentados os padrões definidos para codificação do AvailableD.

4.1. Nomes e Declaração de Variáveis

Os nomes de variáveis seguem o seguinte padrão:

1) A declaração do tipo da variável deve ficar na mesma linha de seu nome. Ex: int i;

2) Primeira letra de cada palavra maiúscula; 3) Sem uso de “_” no nome;

4) Nomes auto explicativos e em inglês;

5) Para mais fácil identificação dos tipos das variáveis, os primeiros caracteres do nome (prefixo), em minúsculo, devem representar o tipo da variável, de acordo com a seguinte tabela:

Tipo Inicial Exemplo

inteiro, long i iCount

float, double n nAverage char, char[], char* s sString

estrutura o oStack

ponteiro Tipo conteúdo + p opStack, spName

função f fCallback

Tabela 1: Prefixos para nomes de variáveis

4.2. Nomes e Declaração de Funções

As funções do AvailableD seguem o seguinte padrão:

1) Iniciam pelo prefixo “able_”. Isso facilita a identificação de funções externas; 2) A declaração do tipo de retorno deve ficar na mesma linha do nome da função;

5) A primeira letra do nome deve ser minúscula. As demais em maiúscula. Ex: able_functionName;

6) O nome da função deve explicar o que a mesma faz. Ex: able_runShellCommand; 7) Parâmetros separados por vírgula mais 1 espaço em branco. Ex:

able_func(int i1, int i2);

8) Não deve haver espaço entre nome da função e abre parênteses. Nos demais detalhes, segue o mesmo padrão dos elementos de controle de fluxo. Ex: able_func();

4.3. Comando de controle de fluxo

A forma de apresentação dos comandos de controle de fluxo são de grande influência na legibilidade do código, pois os mesmos dividem o código em blocos. Sendo assim, devem ser seguidos os seguintes padrões:

1) Após o nome do comando, deve ter um espaço em branco e então o abre parênteses. Ex: if (;

2) Não deve haver espaço entre os parênteses e seu conteúdo. Ex: if (condition); 3) Após o fecha parênteses deve ter um espaço em branco e então o abre chaves. Ex:

while (condition) {;

4) O fecha chaves deve ser alinhado com a primeira letra do nome do comando. Ex: switch (i) {

}

5) Sempre que houver mais de uma linha de código interna ao comando, deve ser deixada uma linha em branco antes e depois do código interno. Ex:

for (i = 0; i < 10; i++) { declaração1;

declaração2; }

6) Quando o código dentro dos parênteses for muito extenso, pode ser quebrado e alinhado com o início do código. Quando a quebra for em condições, o operador condicional deve fazer parte da quebra. Ex:

if (condicao1 && condicao2 && condicao3

&& condicao4, && condicao5, && condicao6) {

7) No caso específico do comando for, quando o conteúdo entre os parênteses for muito extenso, a quebra deve seguir o exemplo:

for (expressa_inicio; condicao;

expressao_frim) {

4.4. Chamadas de funções

As chamadas de funções constituem grande parte do código. Para melhor legibilidade das chamadas devem seguir os seguintes padrões:

able_func(i1, i2, i3, i4);

4) Quando o código interno aos parênteses for muito extenso, realiza-se a quebra a partir do segundo parâmetro, alinhando sempre com o início do primeiro. O fecha parênteses deverá ser allinhado com o abre parênteses. Ex:

able_func(i1, i2, i3, i4 );

4.5. Operadores

Padrões:

1) Um espaço em branco entre operadores e operandos. Ex: i1 + i2;

2) Os operadores unários, fazem exceção à regra anterior, pois devem ficar colados aos operandos. Ex: i++;

3) O operador de atribuição e suas variantes devem ficar alinhados pelo símbolo '=' quando em linhas consecutivas de código são realizadas atribuições. Ex:

iSize = 20; iCount += 2; sSeparator = ',';

oStack = able_newStack();

4.6. Identação

A identação é um dos aspectos mais importantes para a legibilidade do fonte. Para o

AvailableD, os padrões de identação são:

1) Sem utilização de TAB;

2) Usar 2 espaços em branco para cada nível de identação;

3) Variáveis globais, definições e funções devem ficar sempre no primeiro nível de identação;

4) A indentação (os 2 espaços) é aplicada ao código interno de cada novo bloco.

4.7. Comentários e Documentação do Código

Padrões:

1) Os comentário devem sempre ser do tipo /* */;

2) Para documentação deve ser utilizado o padrão Javadoc de comentários, que é suportado por muitas ferramentas geradoras de documentação;

3) Em inglês.

4.8. Demais padrões

1) Tudo deverá ser escrito e documentado em inglês, pois é um idioma compreendido pela maioria dos desenvolvedores. É praticamente o idioma padrão para

desenvolvimento de software;

2) Cada linha deve conter no máximo uma instrução. Não deve ser feito algo do tipo: i1 = 1; i2 = 8;

1. Documento de requisitos do Methodology Explorer, disponível em:

http://www.cin.ufpe.br/~mexplorer/metodologia/requisitos/document oRequisitos.doc, acessado em 10/05/2011.

2. PRESSMAN, Roger S. Engenharia de Software. McGraw-Hill, 2006.

3. SOMMERVILLE, Ian. Software Engineering. 8ª ed. Addison Wesley, 2006. 4. WIKIPEDIA. Engenharia de Requisitos. [Online]. Disponível em:

http://pt.wikipedia.org/wiki/Engenharia_de_requisitos, acessado em 15/06/2011

5. The netfilter.org "iptables" project. [Online]. Disponível em:

http://www.netfilter.org/projects/iptables/, acessado em 01/09/2011 6. WIKIPEDIA. Javadoc. [Online]. Disponível em:

http://en.wikipedia.org/wiki/Javadoc, acessado em 01/10/2011

7. Linux-HA. [Online]. Disponível em: http://www.linux-ha.org, acessado em 02/11/2011

8. Linux Virtual Server. [Online]. Disponível em:

http://www.linuxvirtualserver.org/, acessado em 02/10/2011

9. Nagios. [Online]. Disponível em: http://www.nagios.org/, acessado em 02/10/2011

10.Flex: The Fast Lexical Analyzer. [Online]. Disponível em:

http://flex.sourceforge.net/, acessado em 05/10/2011

11.MSMTP. [Online]. Disponível em: http://msmtp.sourceforge.net/, acessado em 06/11/2011

12.The GNU Transport Layer Security Library. [Online]. Disponível em:

http://www.gnu.org/s/gnutls/, acessado em 06/10/2011 13.The OpenSSL Project. [Online]. Disponível em:

http://www.openssl.org/, acessado em 06/10/2011 14.GNU General Public License. [Online]. Disponível em:

http://www.gnu.org/copyleft/gpl.html, acessado em 07/10/2011 15.Mon - Service Monitoring Daemon. [Online]. Disponível em:

https://mon.wiki.kernel.org/, acessado em 08/10/2011 16.Doxygen Documentation. [Online]. Disponível em: