Você está na página 1de 5

Jacqueline Marques Lara de Almeida

- CODING STANDARD -

Manual de Boas Prticas para Linguagem C

1) Faa sempre um comentrio no incio do cdigo com as seguintes informaes:

Nome do programa;
Objetivo do programa;
Nome do programador;
Data de criao.
2) Utilize nomes simples e claros para rotinas e variveis. O tamanho do nome da varivel no
importante, mas a clareza sim entretanto evite utilizar nomes muito longos.

3) Utilize nomes significativos. Exemplo: no lugar de x = z-y utilize salario_liquido = salario_bruto


descontos;

Isto no quer dizer que os nomes tem que ser obrigatoriamente longos. Voc pode usar
tranquilamente i, j, k para ndices em vetores ou como contadores de loops desde que fique claro
o significado dessas variveis por conveno.

4) Antes do corpo do cdigo de cada funo faa sempre um comentrio explicando o que ela faz.

5) Se a rotina for muito grande importante explicar tambm qual a finalidade de cada varivel a
fim de facilitar o entendimento e a manuteno.

6) Declare as variveis logo aps o ttulo da rotina. No declare as variveis soltas no meio do
cdigo da funo. Organize seu cdigo, sempre declarando as variveis logo aps o ttulo da
rotina e em seguida inicialize-as.

7) Evite repeties de cdigo. Caso um trecho de cdigo aparea vrias vezes no programa,
construa uma rotina e chame-a quando for necessrio. Quanto menor for o tamanho da rotina,
normalmente mais fcil para depurar.

8) Evite a utilizao de Nmeros Soltos no Cdigo: so valores que aparecem no cdigo e so


usados como constantes, embora no tenham sido declarados como tal. Ao invs de usar o
nmero utilize uma constante previamente declarada com #define.
Exemplo:

Ao invs de escrever o cdigo usando os valores como a seguir:

if( consumo < 700 )


{
tarifa = consumo * 0.90;
}

Seria mais interessante substituir os nmeros por constantes com os nomes adequados:

if( consumo < LIMITE )


{
tarifa = consumo * FATOR_DESCONTO;
}

9) Utilize o espaamento de forma a tornar o cdigo mais legvel.

Veja o exemplo:

for(i=0;i<=10;i++)
{

Observe como usando espaamento de forma adequada dentro do for o comando torna-se muito
mais legvel:

for ( i = 0; i <= 10; i++)


{

10) Declare as constantes no incio do cdigo e nunca no meio do mesmo.

11) Utilize sempre letras maiusculas para nomear as constantes em linguagem C.

Exemplo:

#define LIMITE 700


#define FATOR_DESCONTO 0.90

12) Utilize sempre { } mesmo que seja para apenas um comando dentro do bloco.

13) No exagere nos comentrios. Comandos bvios no precisam ser comentados.


Veja um exemplo:

i++; /* incrementando i */

Esse o tipo de comentrio completamente desnecessrio, pois qualquer programador C sabe o


significado do comando.

14) Explique frmulas complexas e passos complicados de um determinado algoritmo. Nesses


casos, um comentrio explicativo torna-se obrigatrio a fim de que a manuteno do cdigo possa
ser feita com menos esforo.

15) Escreva os comentrios necessrios na medida que for escrevendo o cdigo. No escreva o
cdigo e deixe para comentar depois. bem mais fcil elaborar os comentrios quando voc
ainda se lembra dos detalhes.

16) O objetivo da indentao o de tornar os programas mais facilmente legveis. A utilizao de


regras de indentao consistentes permite tornar evidente a estrutura global do programa atravs
de uma simples inspeo visual. A ideia geral a de tornar claramente visveis todas as
instrues compostas (conjunto de instrues entre chaves) indentando (precedendo de espaos)
todas as instrues que as compem um nmero fixo de espaos.

Nesse Manual de Boas Prticas vamos adotar o seguinte estilo:

17) O cdigo-fonte deve usar apenas comentrios no estilo /* */.

18) Para evitar estouro de pilha Funes no podem chamar elas mesmas direta ou
indiretamente.

19) Coloque nas funes, que imprimem alguma mensagem, como ltimo caractere de impresso,
um comando de fim de linha (n ou WriteLine).

20) Escreva um comando por linha.

21) Escreva sempre chaves nos comandos de controle (if/else, while, for etc.), mesmo que no
seja obrigatrio.

22) Digite as chaves, parnteses e colchetes (abrindo e fechando) antes de digitar os comando ou
expresses entre eles.
23) Imprima mensagens de erro em expresses que tenham restries de valores, tais como
diviso por zero, raiz quadrada de nmero negativo, entrada de dados invlidas, dentre outras.

24) Explicite os valores dos flags nas entradas de dados que os contm.

25) Evite alterar as variveis de controle do lao for, dentro do corpo do lao.

26) Coloque sempre o default no comando switch para chamar a ateno em casos excepcionais.

27) Evite o operador ternrio: o ternrio, que utilizado em excesso pode tornar as expresses
pouco legveis aos olhos menos treinados.

A operao

aux = ( cont < aux ) ? cont : cont * -1;

poderia ser escrita, sem nenhum prejuzo, como:

if ( cont < aux ){


aux = cont;
}
eles {
aux = cont * -1;
}
28) O nmero de variveis globais deve ser pequeno.

29) Realize os testes necessrios.

As fases dos Testes de Softwares so divididas em 4 etapas: Testes Unitrios, Testes de


Integrao, Testes de Sistema e Testes de Aceitao. Abaixo a caracterstica de cada um:

30) Teste de Unidade

o estgio mais baixo da escala de testes e so aplicados nos menores componentes de cdigo
criados. So aplicados de maneira individual a cada unidade do sistema. Utiliza as tcnicas de
teste de caixa branca para a sua execuo, e normalmente realizado pelo prprio programador.

31) Teste de Integrao

o processo de verificar a interao entre os componentes. Para que esta fase seja executada,
os mdulos j devem ter passado pelos testes unitrios. Ser dada mais nfase interface entre
os mdulos que esto sendo analisados.

32) Teste de Sistema


Nesta etapa o software testado por completo. Os testes que so aplicados so do tipo caixa-
preta. Nesta fase se verifica a conformidade com os requisitos, simulando um ambiente de
produo real.

33) Testes de Aceitao

Tambm chamados de teste Alfa e Beta, so realizados para permitir ao usurio final validar todos
os requisitos. Nesta fase o cliente confirma se todas as suas necessidades foram atendidas pelo
sistema. Coloque-se no lugar de usurio para simular esse teste.

34) Falhas podem ser originadas por diversos motivos, por isto, testar se torna cada dia mais
importante e essencial para desenvolver software de alta qualidade e garantir a tranquilidade das
operaes.