Evolução dos padrões de codificação, como você lida com eles?

Como você lida com a evolução nos padrões de codificação / guia de estilo em um projeto para a base de código existente? Digamos que alguém da sua equipe descobriu uma maneira melhor de instanciação de objetos na linguagem de programação. Não é que a maneira antiga seja ruim ou com bugs, é apenas que a nova maneira é menos detalhada e parece muito mais elegante. E todos os membros da equipe realmente gostam. Você mudaria todo o código existente?

Digamos que sua base de código tenha mais de 500.000 linhas de código. Você ainda deseja alterar todo o código existente? Ou você deixaria apenas o novo código aderir ao novo padrão? Basicamente, perde consistência?

Como você lida com a evolução dos padrões de codificação do seu projeto?

Existem padrões de codificação para tornar as equipes mais produtivas. Em teoria, eles tornam o código mais fácil de entender, alterar e testar. Na prática, eles podem criar uma quantidade perigosa de meta-trabalho; as equipes reescrevem o código existente repetidamente em busca da solução mais correta e elegante. Infelizmente, o problema do meta-trabalho parece pior em equipes em que todos estão envolvidos, apaixonados e obcecados em fazer a coisa certa.

Como consultor que passa de um projeto para outro, descobri que a excelente disciplina com um padrão rígido de codificação contribui muito menos para o sucesso de um projeto do que excelentes desenvolvedores interessados ​​em resultados. Estilos de codificação inconsistentes são um incômodo menor para desenvolvedores incríveis. Eles são produtivos com ou sem consistência. É verdade que, se encontrarem um código inconsistente, perguntarão sobre o atualpadrão e ficar com ele. No entanto, eles não insistirão em atualizar todas as linhas de código do projeto para o padrão atual. Eles não insistem porque viram as melhores práticas ir e vir. A maneira correta de fazer algo hoje não é a mesma maneira correta de fazer algo amanhã. Se fosse, seus padrões de codificação não evoluiriam. Portanto, se a maneira correta de fazer algo mudar com o tempo, talvez nossa definição de "correto" esteja quebrada.

Isso não quer dizer que os padrões não importem. Lembre-se de que o objetivo dos padrões é a produtividade. Se você não pode garantir que a reescrita para um novo padrão se pagará a longo prazo, não perca tempo com isso. É muito mais fácil justificar um novo padrão em código novo ou refatorado. Elegância é legal, mas não é o mesmo que resultados.

O que fazemos é evolução (não revolução) para a base de código também, usaríamos o padrão atualizado quando;

• novo código é escrito
• código é refatorado
• bugs são corrigidos
• novas partes são adicionadas a uma classe existente

É importante que sua base de código seja consistente; portanto, se a alteração abrir uma possibilidade de confusão entre o código de estilo "antigo" e o "novo", talvez seja melhor reservar a atualização do seu padrão de codificação para o próximo projeto.

Antes de tudo, não incluiria essas "melhores práticas" nas (parte obrigatória das) diretrizes de codificação. Eles podem ser mencionados, por exemplo, em um apêndice, como um exemplo de como você pode fazer algo, mas não que isso deva ser feito dessa maneira.

Dito isto, há dois casos a serem considerados para alterações em um padrão de codificação:

1. Alterações que não afetam a legibilidade, mesmo que o código antigo e o novo sejam misturados sem atualizar o código antigo.
   Essas alterações podem ser adicionadas ao padrão de codificação imediatamente e devem ser consideradas em vigor para todos os códigos novos e modificados. O código antigo deve ser adaptado gradualmente conforme o tempo permitir e as alterações nessa área.
   Um exemplo desse tipo de alteração, que eu realmente encontrei, é uma alteração na declaração de direitos autorais no início de cada arquivo.
2. Alterações que deterioram a legibilidade se código antigo e novo forem misturados.
   Essas alterações devem ser aplicadas a toda a base de código de uma só vez ou devem ser reconsideradas se forem realmente necessárias.
   Um exemplo desse tipo de alteração é uma alteração no recuo ou no posicionamento da chave.

Isso realmente depende do tipo de produto que você está criando:

• Para um aplicativo comercial escrito internamente e você está implantando para os clientes, seu principal objetivo deve ser a receita. Desde que o código antigo não seja de buggy, não importa que novos padrões de codificação tenham evoluído, você deve se concentrar em adicionar novos recursos ao seu produto e gerar receita. De qualquer modo, adapte os novos padrões de codificação ao novo código, mas alterar todo o código existente seria uma perda de tempo.
• Se você estiver desenvolvendo um produto de código aberto ou um produto em que várias empresas (talvez até seus clientes) verão e trabalhem na fonte, a legibilidade do código se tornará muito mais importante e, nesse caso, uma decisão sensata deverá ser tomada, dependendo exatamente quanto código precisa ser alterado e quais serão os benefícios a longo prazo. Embora todos gostemos de código bonito, a realidade é que, para uma empresa comercial que lida com código fechado, a adaptação constante de novos padrões significa que você perderá receita a longo prazo.

Pessoalmente, eu optaria por manter os códigos antigos como estão e seguir novos padrões de qualquer coisa que você faça de novo. Mais especificamente, não utilizarei padrões duplos no old.c. Mas se vou criar new.c, ele pode usar as sintaxes mais recentes e refinadas :)