Princípios

Estes princípios não reflectem apenas aspectos "decorativos" dos algoritmos. O estilo e a estética são essenciais para a elaboração, para a compreensão, para o "debug" e para a manutenção do "software". Estamos também a falar em termos económicos: uma má programação pode representar imenso dinheiro perdido e muitas dores de cabeça!

É claro que um bom estilo, só por si, não chega para se ter um bom programa. É fundamental saber conceber programas e ter bons conhecimentos na área respectiva.

Cada parte (função, módulo···) de um programa deve ter:
-- Objectivo claro
-- Contexto pequeno (poucas variáveis···visíveis) -- Acesso formalizado.

Princípio. Razão: legibilidade do programa
Nenhuma função (incluindo o main()) deve ter mais que 20 ou 30 linhas de texto.

Princípio. Razão: simplicidade e legibilidade do programa
Cada função deve ter um e um só objectivo que seja facilmente explicável por palavras.

Princípio. Razão: compreensão do programa
Cada função deve ter um curto comentário (1 ou 2 linhas) explicativo. Deve ficar explícito: qual o objectivo da função, quais os parâmetros, qual o resultado. Por exemplo:

    // compara(a,b): compara os inteiros a e b
    //    resultado: -1 se a<b, 0 se a==b, 1 se a>b

Princípio. Razão: evitar erros, organizar a relação entre as funções
Muitas vezes é necessário declarar o tipo das funções antes de as utilizar através de protótipos. Por exemplo int get_next(struct caixa, char); É boa ideia incluir todos os protótipos à cabeça do programa, possivelmente num ficheiro separado inserido pelo pré-processador através da directiva include (com vista a melhorar a legibilidade do programa).

Princípio. Razão: legibilidade do programa e minimização de "estragos": pequeno número de variáveis visivéis da função
O número de variáveis globais deve ser muito reduzido.

Princípio. Razão: legibilidade do programa
As funções devem ter um pequeno número de parâmetros os quais devem estar estruturados de forma apropriada.

Princípio. Razão: não sejamos complicados
O código e as estruturas de um programa não devem ser mais sofisticados que aquilo que é necessário. Maus exemplos: (i) Usar uma lista de apontadores quando um simples vector resolve o problema com a mesma ou mais eficiência; (ii) Usar funções que poderiam ser substituídas, sem perda de legibilidade, por simples instruções; exemplo

    // incrementa(a): o valor do inteiro a é incrementado de uma unidade.
    void incrementa(int *a){
      *a = *a+1;
    }

Princípio. Razão: legibilidade, não sejamos complicados
Evitar instruções crípticas, como for(;c=getchar(),printf("%d\n",c),c!='z';); É preferível escrever

     do{
        c=getchar();
        printf("%d\n",c);
      }
      while(c!='z');

Princípio. Razão: adaptabilidade
Em vez de utilizar constantes explícitas (por exemplo, 16003), defini-las à cabeça utilizando, por exemplo, #define NMAX 16003.

Princípio. Razão: portabilidade
Evitar construções cuja semântica não está definida como a[i+]=2+i++;

Princípio. Razão: poupar tempo de "debug"
Durante a fase inicial de desenvolvimento de um programa, em vez de os dados serem fornecidos interactivamente pelo utilizador, deve inicializar-se as variáveis (simples, vectores, estruturas, etc.) com os valores correspondentes a um caso de teste simples.

Princípio. Razão: legibilidade do programa