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.