Regras e diretrizes de programação melhoram a consistência do código, mas a má aplicação pode levar a resultados ruins. Arne Mertz sugere que os desenvolvedores de software adotem regras e diretrizes de forma seletiva e documentem os desvios com explicações claras. Eles podem discutir suas experiências em comunidades ou durante seu trabalho diário, para fomentar a colaboração e melhorar a qualidade do código sem a burocracia desnecessária.
Arne Mertz deu uma palestra sobre regras e diretrizes de programação no NDC Tech Town.
Regras e diretrizes de programação ajudam os desenvolvedores a trabalharem juntos, o que pode resultar em um código mais consistente e melhor. No entanto, usá-las da maneira errada pode ter o efeito oposto – um código que é difícil de ler ou resolve problemas de maneira subótima ou até errada, como Mertz explicou no artigo da InfoQ sobre como usar regras e diretrizes de programação.
Como exemplo, Mertz mencionou que a Diretriz Central de C++ não torna membros de dados const ou referências em um tipo copiável ou movível. A segunda parte é frequentemente omitida, mas é importante, como ele explicou:
Um membro const não pode ser reatribuído, um membro de referência não pode ser direcionado para referir-se a algo diferente, então um tipo com esse tipo de membro não pode ser atribuído normalmente. O compilador não será capaz de gerar operadores de atribuição de movimento e cópia para esses tipos. Portanto, esses membros não devem ser usados em tipos que são projetados para ter semântica de valor.
Embora esses tipos geralmente compõem uma grande parte dos tipos de uma aplicação, existem outros que não têm semântica de valor, disse Mertz. Ele mencionou serviços de aplicação e repositórios como exemplos. Para esses últimos tipos, é perfeitamente aceitável e normal ter membros de referência, disse Mertz.
Mertz sugeriu pensar sobre quais diretrizes adotar e como documentá-las. Um documento de 50 páginas do Word guardado em alguma página do SharePoint raramente é lido, ele mencionou. Os desenvolvedores não saberão e, portanto, ignorarão a maioria das diretrizes que estão lá.
Muitas diretrizes podem ser verificadas automaticamente, por exemplo, usando clang tidy, mas então precisamos de uma maneira de desligar avisos em casos específicos, porque, afinal, diretrizes não são regras, disse Mertz.
Mertz mencionou que eles têm uma comunidade C++ ativa em sua empresa onde trocam experiências em diferentes projetos. Desenvolvedores mais experientes apoiam seus colegas respondendo perguntas e dando conselhos, ele explicou:
Temos um projeto de exemplo em C++ com um arquivo clang-tidy típico para fornecer alguns padrões sensatos para verificações automáticas das Diretrizes Centrais de C++ e mais.
Mertz mencionou que às vezes discutem o documento de diretrizes do cliente em sua sincronização semanal de desenvolvedores. Mas também criam suas próprias diretrizes mais específicas quando acham que precisam delas:
O processo é pragmático e não muito formal, mas descobrimos que, ao longo do tempo, isso leva a um código mais consistente e de maior qualidade sem a sobrecarga da burocracia.
Parte dessas reuniões poderia ser vista como uma “retrospectiva técnica” onde discutem o que funciona melhor para eles e como evitar armadilhas que encontraram em sua base de código específica, concluiu Mertz.
InfoQ entrevistou Arne Mertz sobre regras e diretrizes de codificação.
InfoQ: Como as regras e diretrizes diferem uma da outra?
Arne Mertz: Uma regra é mais ou menos absoluta, deve ser seguida onde quer que se aplique. Uma diretriz é uma boa prática ou padrão sensato, as pessoas podem divergir e isso é aceitável. Como as diretrizes não são regras, sugiro documentar quando você deliberadamente não segue uma diretriz, por exemplo, com um comentário explicando as razões.
Regras são convenientes – nós, ou nossas ferramentas automáticas, podemos simplesmente apontar para elas e dizer “errado”, e temos que corrigir nosso código. Diretrizes dão mais liberdade, mas também mais responsabilidade – não podemos simplesmente segui-las no piloto automático. No entanto, elas são uma ferramenta importante.
InfoQ: Quais benefícios as equipes de desenvolvimento de software podem obter ao usar diretrizes?
Mertz: Quando uma equipe segue diretrizes comuns, sabemos o que esperar do código. O “Princípio da Menor Surpresa” é um princípio de design importante que torna o código mais fácil de ler e entender.
Mesmo como leitor de código, saber as diretrizes que ele segue é útil: se um leitor está familiarizado com diretrizes de codificação e convenções de escrita em geral, é mais fácil identificar código não convencional que pode precisar de uma análise mais cuidadosa.