Boas práticas para o desenvolvimento de software – Algumas ideias de como organizar o seu software – II

Caro Colega,

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 parteonde é 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 subrotinas:

Quando for escrever uma nova subrotina para o seu programa, é de grande ajuda você escrever um cabeçalho destacado, conforme pode-se ver na Figura 1, listando nos comentários o nome da subrotina, 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.

Rotina em C para escrita na E2PROM

Figura 1 – Exemplo de Rotina em C para escrita na E2PROM

Essa figura é um extrato da subrotina mostrada 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, subrotinas, constantes, etc. que façam a relação dessas variáveis com sua função, destino, etc. No exemplo que temos na Figura 1:

  • vEscreveE2PROM(unsigned char nEndereço, unsigned char nDado)
  • bFlagDeErro = DESLIGA;
Na Figura 1, pode-se reparar que algumas variáveis estão escritas em letras maiúsculas, por exemplo, LIGA, DESLIGA, SDA e SCL.
No início do programa, foram definidas as constantes com esses nomes, SCL e SDA fazendo referência aos sinais de controle de uma EEPROM serial com comunicação por dois fios. Isso você pode conferir no extrato do programa exibido na Figura 2 abaixo.
Exemplo de como definir mnemonicamente as variáveis

Figura 2 – Exemplo de como definir algumas variáveis utilizando boas práticas para desenvolver software

 

Para auxiliar na compreensão você pode consultar a Figura 3, onde se vê as conexões entre a CPU e a EEPROM correspondentes a esse programa.

Conexões entre CPU e EEPROM

Figura 3 – Esquema Elétrico mostrando as conexões entre CPU e EEPROm

Na Figura 4,   está ilustrada a primeira página do manual de uma dessas EEPROMs.

EEPROM comunicação 2 fios

Figura 4: Exemplo de EEPROM serial com comunicação a 2 fios

Essas constantes também estão associadas a bits específicos de uma 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.

Notação Húngara

Segundo a definição do Wikipedia:

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.

Por enquanto é só. Dê  a sua opinião, críticas e sugestões. Confira no próximo artigo:

Abraço!

 

Henrique

consulte sempre um engenheiro eletrônico

 

Licença Creative Commons Esta obra, “Boas práticas para o desenvolvimento de software – Algumas ideias de como organizar o seu software – II“, de Henrique Frank W. Puhlmann, foi licenciada sob uma Licença Creative Commons Atribuição-NãoComercial-CompartilhaIgual 3.0 Não Adaptada.

2 comentários sobre “Boas práticas para o desenvolvimento de software – Algumas ideias de como organizar o seu software – II

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google

Você está comentando utilizando sua conta Google. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s