Boas práticas para o desenvolvimento de software - Parte 2
Boas práticas para o desenvolvimento de software - Parte II
- Boas praticas - introdução
- Boas praticas - Parte I
- Boas práticas - Parte II
- Nos segmentos anteriores da série Boas práticas para o desenvolvimento de software, foram apresentados: uma introdução ao assunto, onde é mostrada a necessidade de boas práticas como uma forma de melhorar a produtividade na geração e manutenção de software e de qualidade desse software gerado e a primeira parte, onde é abordada a ideia de se desenvolver o software de forma estruturada, porém utilizando alguns métodos de encapsulamento de dados.
Nessa segunda parte vamos abordar mais alguns aspectos envolvendo ideias para organizar e melhorar o seu software. Aí vão mais algumas sugestões:
Cabeçalho de sub-rotinas
Quando for escrever uma nova sub-rotina para o seu programa, é de grande ajuda você escrever um cabeçalho destacado, conforme se pode ver na Figura 1, listando nos comentários o nome da sub-rotina, uma pequena descrição das operações que ela realiza, uma lista de variáveis de entrada, com descrição se necessário e uma descrição das variáveis de saída.
Figura 1: Exemplo de um cabeçalho de sub-rotina
Esse código é o cabeçalho de uma das sub-rotinas mostradas na primeira parte dessa série. As vantagens são óbvias. Quando no decorrer do desenvolvimento do programa você necessitar de uma rotina que realiza determinada função, você pode conferir se entre as que você já escreveu tem alguma, só lendo a descrição do cabeçalho. Depois, esse esquema facilita a depuração durante uma eventual manutenção após um longo período. O destaque realizado em torno do cabeçalho, facilita encontrar as rotinas quando se vasculha o programa.
Escolher nomes significativos para variáveis e rotinas
Dar nomes às variáveis, sub-rotinas, constantes, etc. que façam a relação dessas variáveis com sua função, destino, etc. No exemplo que temos no código acima:
- vEscreveE2PROM (unsigned char nEndereço, unsigned char nDado);
- bFlagDeErro = DESLIGA.
OBS: Se você quiser ver a sub-rotina completa, abra a janela a seguir:
Figura 2: Extrato das definições de mnemônicos
Essas constantes também estão associadas a bits específicos de um Port do microcontrolador. Nomear uma variável de SDA é bem mais inteligível do que P2_5, por exemplo (Port 2, bit 5). As constantes LIGA e DESLIGA foram definidas como ’1′ e ’0′ respectivamente. Isso tudo nos leva ao próximo tópico desse artigo: A polêmica notação húngara.
Boas práticas para o desenvolvimento de software – Notação Húngara
Segundo a definição do Wikipedia:
A Notação Húngara, criada por Charles Simonyi, visa a facilitar o reconhecimento do tipo de variável num programa. O nome foi dado a partir de uma brincadeira comum entre os primeiros a conhecer a notação que a achavam estranha, fazendo o seguinte comentário: “É tão estranho que até parece húngaro”. Quando se confronta com a necessidade de dar um novo nome a uma variável num programa, o programador deve tomar alguns cuidados ao tomar essa decisão:
- Nome mnemônico – é aquele que facilita a lembrança do significado pelo programador;
- Nome sugestivo – é aquele em que outros podem ler o código;
- Formato – é sempre visto como uma ideia estética, tendo sempre uma informação eficiente do programa teste;
- Velocidade de decisão – não se pode perder muito tempo para ponderar um simples nome, pois não haverá tempo para editar e digitar nomes de variáveis longos.
A adoção deste critério de nomeação é bastante prática e intuitiva, sendo a ideia básica nomear todos os tipos de quantidades, visando-se a simplificar o entendimento do programa. Algumas vantagens deste método:
- Os nomes em mnemônicos são utilizados num senso muito específico. Se alguém se lembrar da quantidade ou como os nomes foram construídos através de outros tipos, o nome poderá ser lido facilmente.
- Os nomes sugestivos são muito bons. É capaz de se mapear qualquer nome dentro do seu tipo, tendo as informações necessárias para construir sua interface e utilizar de maneira correta sua quantidade.
- Os nomes devem ser consistentes, porque eles são construídos pelas mesmas regras.
- A decisão por um nome deve ser mecânica e rápida.
- As expressões nos programas devem ser sugestivas, facilitando a leitura e acompanhamento do programa.
Com o objetivo de fazer listas intuitivas de se ler, os programas baseados na plataforma Windows utilizam a Notação húngara para gerar estas listas. As regras para se utilizar a Notação húngara são:
- Os tipos definidos e/ou criados devem aparecer em letras maiúsculas;
- constantes e “Macros” que vêm definidas em arquivos inclusos aparecem também em letras maiúsculas;
- Funções e nomes estruturados começam com letras maiúsculas. Nenhuma marca abaixo são utilizadas para nomes, exceto para os casos que se encontrem nas duas regras anteriores;
- Nomes de objetos começam com uma ou mais letras maiúsculas, indicando o tipo do objeto.
A tabela abaixo indica os tipos de indicadores mais utilizados na Notação húngara:
NOME | DESCRIÇÃO |
---|---|
s | String |
sz | Aponta o primeiro caracter da terminação zero da string |
st | Ponteiro da string, o primeiro byte é contado dos caracteres |
h | handle (título) |
msg | Message |
fn | function (usada com pointer) |
c | char (8 bits) |
by | unsigned char (byte or uchar – 8 bits) |
n | Int |
b | Boolean (verdadeiro ou falso) |
f | Flag (boolean, logical). Se qualificado é usado, pode descrever o estado verdadeiro do flag. Exceção às constantes. |
u | integer |
w | Word |
ch | Char, com texto ASCII |
l | long int (32 bits) |
dw | unsigned long int (dword – 32 bits) |
Essa notação é um pouco confusa e complicada e é alvo de muita polêmica sobre a sua eficiência e necessidade de uso. Na minha opinião e na minha experiência, essa notação, ou outra qualquer mais simplificada que você queira utilizar, facilita muito o reconhecimento das variáveis e funções, não só pelo nome, como também o tipo, por exemplo bit, byte, inteiro, float, string, long, etc. Pense no assunto, experimente utilizar, eu tenho certeza que em pouco tempo você vai gostar do resultado final.