Semanticamente, “bufferVazio” é um booleano, mas sintaticamente ele continua sendo um int. O que o padrão quer nos dizer é que devemos fazer as comparações explicitas, ou seja, se desejamos verificar se o buffer esta vazio, esta implementação está fora do padrão:

if (bufferVazio) { … };

E esta esta dentro do padrão:

if (bufferVazio == 1) { … };

Eu concordo com você, e acho a primeira forma mais fácil de ler.

Um abraço,

Sergio Prado

Ficou muito bom o seu artigo, padronização de código é um assunto muito importante que merece ser discutido. Toda iniciativa de estilização é benéfica, levando a uma maior manutenabilidade do software.

Como sempre seu blog é uma excelente fonte de informações úteis e profissionais.

Abraço.

Com relação à regra 49, quando uma variável representa um valor boolean, ou seja, que pode assumir apenas true (1) ou false (0), eu acho muito mais fácil de ler o código sem ter que comparar com 0 ou 1, como exige o padrão. Com relação à regra 20.4, você fez uma ótima observação. Ainda não tinha considerado esta hipótese. E o Hugo participa bastante do grupo sis_embarcados, do qual agora você também faz parte…:) Estou te enviando o email dele em PVT. Um abraço e continue acompanhando o blog!

Seu comentário é quase um novo post…:)

Obrigado pelas dicas valiosas e continue aparecendo por aqui.

Um abraço!

Parabens pela iniciativa, de fato sinto falta de artigos relacionados ao tema na nossa língua portuguesa.
Venho trabalhando com desenvolvimento de sistemas críticos já há alguns anos e hoje utilizo a MISRA-C como padrão de codificação. Vale à pena ressaltar a diferença entre padrão de codificação e padrão de desenvolvimento (ou design). Para desenvolver sistemas críticos é necesssario ter estes padrões definidos. Interessante notar também que adoptar uma padrão de codificação não é apenas boa prática quando se trata de sistemas críticos (SC): é mesmo uma obrigação. Padrões de codificação são requeridos por diferentes normas que defendem desenvolvimento de SC (veja a DO-178B, IEC-61508, EN-50128).
Quanto ao padrão MISRA-C, os justificativas para cada regra são muito bem explicadas na própria norma, por isso recomendo sua leitura a qualquer um que pense seriamente em aplicá-la. Lá vc vai ver também que nem todas as regras são normativas, há também regras opcionais.

O que tenho visto como experiência geral é que MISRA-C não tem por propósito somente “educar” desenvolvedores inexperientes. Desenvolver software para SC pode ser uma tarefa extremamente árdua pelo simples fato de construções mais elaboradas da linguagem não serem permitidas.Tomando como exemplo a regra comentada em seu artigo sobre alocação dinâmica de memória (regra 20.4, uma das requeridas pela norma). Num sistema crítico, é imprescindível saber a priori quantos e quais são os recursos utilizados pela aplicação. Mais que isso, é preciso demonstrar, que a quantidade de memória utilizada nunca ultrapassará o limite disponível (suponha que o programa falhe de uma maneira catastrófica caso não haja memória disponível). Quando se usa alocação dinâmica de memória é extremamente difícil provar esta ‘propriedade’. Portanto MISRA-C fala muito também à comunidade de programadores experientes em C, mas que podem não estar devidamente contextualizados as necessidades da natureza deste tipo de aplicação.

Abraços,
Hugo Sobreira

Ótima observação. A minha interpretação é que a regra quis dizer que você não precisa fazer uma comparação explicita apenas se sua variável for do tipo boolean. O exemplo abaixo é permitido pelo padrão MISRA-C:

bool bufferVazio;

if (bufferVazio) {
return;
}

Veja que a variável “bufferVazio” é do tipo bool. O tipo bool está especificado no padrão ANSI C99.

Um abraço,

Sergio Prado