As 10 regras de codificação para escrever o programa crítico de segurança da NASA

Projetos de software grandes e complexos usam vários padrões e diretrizes de codificação. Essas diretrizes estabelecem as regras básicas que devem ser seguidas ao escrever software. Normalmente, eles determinam:

a) Como o código deve ser estruturado?
b) Qual recurso de idioma deve ou não ser usado?

Para ser eficaz, o conjunto de regras deve ser pequeno e específico o suficiente para ser facilmente compreendido e lembrado.

Os principais programadores do mundo que trabalham na NASA seguem um conjunto de diretrizes para o desenvolvimento de códigos essenciais para a segurança. Na verdade, muitas agências, incluindo o Jet Propulsion Laboratory (JPL) da NASA, se concentram em código escrito em linguagem de programação C. Isso ocorre porque há um amplo suporte de ferramentas para essa linguagem, como extratores de modelo lógico, depuradores, compilador estável, analisadores de código-fonte fortes e ferramentas de métricas.

Em casos críticos, torna-se necessária a aplicação dessas regras, especialmente onde a vida humana pode depender de sua correção e eficiência. Por exemplo, programas de software usados ​​para controlar aviões, espaçonaves ou usinas nucleares.

Mas você sabe quais padrões as agências espaciais usam para operar suas máquinas? Abaixo, listamos as 10 regras de codificação da NASA estabelecidas pelo cientista-chefe do JPL, Gerard J. Holzmann. Todos eles se concentram principalmente nos parâmetros de segurança, e você também pode aplicá-los a outras linguagens de programação.

Regra nº 1 - Fluxo de controle simples

Escreva programas com construções de fluxo de controle muito simples - Não use setjmp ou longjmp constrói, goto declarações e recursão direta ou indireta .

Razão: O fluxo de controle simples resulta em clareza de código aprimorada e recursos mais fortes para verificação. Sem recursão, não haverá gráfico de chamada de função cíclica. Assim, todas as execuções que deveriam ser limitadas permanecem realmente limitadas.

Regra nº 2 - Limite superior fixo para loops

Todos os loops devem ter um limite superior fixo. Deve ser possível para uma ferramenta de verificação provar estaticamente que um limite superior predefinido no número de iterações de um loop não pode ser excedido.

A regra é considerada violada se o limite do loop não puder ser provado estaticamente.

Razão: A presença de limites de loop e a ausência de recursão impedem o código de fuga. No entanto, a regra não se aplica a iterações que devem ser não encerradas (por exemplo, agendador de processo). Nesses casos, a regra reversa é aplicada - deve ser estaticamente provável que a iteração não pode terminar.

Regra nº 3 - Sem alocação de memória dinâmica

Não use a alocação de memória dinâmica após a inicialização.

Razão: Alocadores de memória como malloc e os coletores de lixo geralmente têm um comportamento imprevisível que pode impactar excepcionalmente o desempenho. Além disso, erros de memória também podem ocorrer por causa de um erro do programador, que inclui

• Tentativa de alocar mais memória do que a disponível fisicamente
• Esquecer de liberar memória
• Continuar a usar a memória depois de liberada
• Ultrapassando os limites da memória alocada

Forçar todos os módulos a residir em uma área de armazenamento fixa e pré-alocada pode eliminar esses problemas e tornar mais fácil verificar o uso da memória.

Uma maneira de solicitar memória dinamicamente na ausência de alocação de memória do heap é usar a memória da pilha.

Regra nº 4 - Sem grandes funções

Nenhuma função deve ser mais longa do que o que poderia ser impresso em uma única folha de papel em um formato de referência padrão com uma linha por declaração e uma linha por declaração. Isso significa que uma função não deve ter mais de 60 linhas de código.

Razão: Funções excessivamente longas costumam ser um sinal de estrutura deficiente. Cada função deve ser uma unidade lógica que seja compreensível e também verificável. É muito mais difícil entender uma unidade lógica que se estende por várias telas em um monitor de computador.

Regra nº 5 - Baixa densidade de afirmação

A densidade de asserções do programa deve ter, em média, no mínimo duas assertivas por função. Asserções são usadas para verificar se há condições anormais que nunca deveriam acontecer em execuções na vida real. Eles devem ser definidos como testes booleanos. Quando uma asserção falha, uma ação de recuperação explícita deve ser executada.

Se uma ferramenta de verificação estática provar que a asserção nunca pode falhar ou nunca se manter, a regra é considerada violada.

Razão: De acordo com as estatísticas de esforço de codificação da indústria, os testes de unidade capturam pelo menos um defeito por 10 a 100 linhas de código. As chances de interceptar defeitos aumentam com a densidade de afirmações.

O uso de asserção também é importante, pois eles fazem parte de uma forte estratégia de codificação defensiva. Eles são usados ​​para verificar as pré e pós-condições de uma função, parâmetro e valor de retorno de uma função e invariantes de loop. As asserções podem ser desabilitadas seletivamente após testar o código de desempenho crítico.

Regra nº 6 - Declarar objetos de dados no menor nível de escopo

Este apóia o princípio básico de ocultação de dados. Todos os objetos de dados devem ser declarados no menor nível de escopo possível.

Razão: Se um objeto não estiver no escopo, seu valor não pode ser referenciado ou corrompido. Esta regra desencoraja a reutilização de variáveis ​​para finalidades múltiplas e incompatíveis que podem complicar o diagnóstico de falhas.

Leia:20 maiores programadores de computador de todos os tempos

Regra nº 7 - Verifique os parâmetros e o valor de retorno

O (s) valor (es) de retorno das funções não nulas devem ser verificados por cada função de chamada, e a validade dos parâmetros deve ser verificada dentro de cada função.

Em sua forma mais estrita, esta regra significa até mesmo o valor de retorno de printf declarações e arquivo fechar declarações devem ser verificadas.

Razão: Se a resposta a um erro não for diferente, por direito, da resposta ao sucesso, deve-se verificar explicitamente um valor de retorno. Esse geralmente é o caso com chamadas para fechar e printf . É aceitável converter explicitamente o valor de retorno da função para void - indicando que o codificador explicitamente (não acidentalmente) decide ignorar um valor de retorno.

Regra nº 8 - Uso limitado do pré-processador

O uso do pré-processador deve ser limitado à inclusão de arquivos de cabeçalho e definições de macro. Chamadas recursivas de macro, colagem de tokens e listas de argumentos de variáveis ​​não são permitidas.

Deve haver justificativa para mais de uma ou duas diretivas de compilação condicional, mesmo em grandes esforços de desenvolvimento de aplicativos, além do clichê padrão, que evita a inclusão múltipla do mesmo arquivo de cabeçalho. Cada um desses usos deve ser sinalizado por um verificador baseado em ferramenta e justificado no código.

Razão: O pré-processador C é uma ferramenta poderosa e ambígua que pode destruir a clareza do código e confundir muitos verificadores baseados em texto. O efeito das construções em código de pré-processador ilimitado pode ser excepcionalmente difícil de decifrar, mesmo com uma definição de linguagem formal em mãos.

O cuidado contra a compilação condicional é igualmente importante - com apenas 10 diretivas de compilação condicional, pode haver 1.024 versões possíveis (2 ^ 10) do código, o que aumentaria o esforço de teste necessário.

Leia:9 novas linguagens de programação para aprender este ano

Regra nº 9 - Uso limitado de indicadores

O uso de ponteiros deve ser restrito. Não é permitido mais do que um nível de desreferenciamento. As operações de desreferenciação do ponteiro não devem ser escondidas dentro de typedef declaração ou definições de macro.

Ponteiros de função também não são permitidos.

Razão: Os ponteiros são facilmente mal utilizados, mesmo por especialistas. Eles tornam difícil seguir ou analisar o fluxo de dados em um programa, especialmente por analisadores estáticos baseados em ferramentas.

Os ponteiros de função também restringem o tipo de verificação realizada por analisadores estáticos. Assim, eles só devem ser usados ​​se houver uma forte justificativa para sua implementação. Se ponteiros de função forem usados, torna-se quase impossível para uma ferramenta provar a ausência de recursão, portanto, métodos alternativos devem ser fornecidos para compensar essa perda nas capacidades analíticas.

Leia:14 o melhor software de programação para escrever código

Regra nº 10 - Compilar todo o código

Todo o código deve ser compilado desde o primeiro dia de desenvolvimento. O aviso do compilador deve ser habilitado na configuração mais meticulosa do compilador. O código deve ser compilado com essas configurações sem qualquer aviso.

Todo o código deve ser verificado diariamente com pelo menos um (de preferência mais de um) analisador de código-fonte estático de última geração e deve passar no processo de análise sem aviso prévio.

Razão :Existem muitos analisadores de código-fonte eficazes disponíveis no mercado; alguns deles são ferramentas freeware. Não há absolutamente nenhuma desculpa para qualquer codificador não fazer uso dessa tecnologia disponível. Se o compilador ou analisador estático ficar confuso, o código que está causando a confusão / erro deve ser reescrito para que se torne mais trivialmente válido.

Leia:30 incríveis invenções da NASA que usamos em nossa vida diária

O que a NASA diz sobre essas regras?