Em uma "promoção relâmpago" da Netrino, tive a oportunidade de comprar seu padrão para desenvolvimento de software embarcado em C por míseros $9.

Assim como todo bom padrão de codificação, seu objetivo é diminuir a quantidade de bugs, melhorar a legibilidade, a manutenibilidade e a portabilidade de seus códigos em C.

Quem acompanha meu blog sabe da importância que dou para este tipo de assunto, vide meus artigos sobre a história e os padrões da linguagem C, e o padrão MISRA-C.

Mas este documento da Netrino define algumas normas que se aproximam bastante da nossa realidade como desenvolvedor de software embarcado em C, já que não é tão aberto à interpretações como o padrão C99, nem tão restritivo quanto o MISRA-C.

Michael Barr, autor do documento, e que já foi entrevistado por mim aqui, é uma personalidade conhecida no mercado mundial de embarcados, e teve a ajuda de outras personalidades como Nigel Jones, Jack Ganssle e Jean Labrosse na elaboração do padrão.

A principal premissa seguida pelo documento é a de que existe um trabalho contínuo em um produto com software embarcado. Apesar de alguns desenvolvedores pensarem o contrário, o código que você esta desenvolvendo não é seu, e sim da empresa em que atua! A não ser que esta empresa seja sua mesmo…:)

E um dia você, ou outra pessoa, precisará dar manutenção no código. Ou então o código é complexo o bastante para envolver uma equipe de vários desenvolvedores, cada um trabalhando em um módulo do software. Como coordenar este trabalho conjunto? Como garantir que todos "falarão a mesma língua"? Sem um padrão, fica realmente muito difícil.

E tem muita coisa boa nesse documento, incluindo regras como:

• Todo bloco deve explicitamente abrir e fechar chaves.
• Ser explícito no uso de parênteses.
• Usar #if 0 para comentar código.
• Escrever comentários antes de começar a codificar, mesmo porque você deve saber explicar o algoritmo antes de escrever uma linha de código.
• Usar o Doxygen para gerar documentação do código.
• Usar uma ferramenta de Lint para análise estática de código (escrevi um artigo sobre análise estática de código aqui).
• Usar um Code Beautifier para formatar o código (eu uso o astyle).
• Definir uma variável apenas quando precisar dela, o que facilita a leitura do código e está dentro do padrão C99.

Confesso que não concordei 100% com o documento, como por exemplo as regras abaixo:

• Manter o código-fonte limitado a 80 colunas. Isso fazia sentido quando desenvolvíamos em monitores monocromáticos e imprimíamos o código em impressoras matriciais. Hoje, na minha opinião, já não é tão importante assim.
• Não usar goto, continue e break. Ainda acho que estas palavras-chave possuem alguma utilidade bem específica. Este meu post sobre goto pode explicar.
• Não usar short ou long. Por quê? Desde que protegidas com typedef, não vejo motivo em não utilizá-las.
• Não usar vírgula na declaração de variáveis. Esta regra visa resolver problemas do tipo "char * x, y;", quando queremos declarar ambas variáveis como ponteiro. Neste caso, o correto seria "char *x, *y;". Mas discordo que, por causa deste tipo de problema, precisamos necessariamente declarar cada variável em uma linha. Uma função com 5 variáveis do tipo char precisaria de 5 linhas para declará-las. Acho isso desnecessário, e pode até piorar a legibilidade do código. Acredito que devemos tratar o caso da declaração de ponteiros como exceção, e não como regra.

Ao todo, são 105 páginas com boas práticas de desenvolvimento em C para sistemas embarcados. No final do documento o autor disponibiliza modelos de arquivo fonte (.c) e header (.h).

Se você tiver a oportunidade, vale a pena comprar o documento. A propósito, não estou ganhando um centavo com isso, e até acho seu valor demasiado caro.

Mas pensando bem, aquela "uma horinha" que você ou sua equipe perderam procurando um bug no software que poderia ter sido evitado seguindo algumas boas práticas, teriam pago o investimento, e com sobras!

Um abraço,

Sergio Prado