Isso é realmente entre você e seus companheiros de equipe. Ninguém mais pode te dizer a resposta certa. No entanto, se eu puder ousar ler nas entrelinhas, o fato de você chamar esse estilo de "ruim" fornece algumas informações que sugerem que é melhor ir devagar. Muito poucos estilos de codificação são realmente "ruins". Há aqueles que eu não usaria, mas eles sempre têm uma rima ou razão para eles. Isso sugere, para mim, que há mais na história do que você viu até agora. Perguntar ao redor seria uma chamada muito sábia. Alguém pode saber algo que você não sabe.
Eu me deparei com isso, pessoalmente, na minha primeira incursão na codificação de missão crítica em tempo real. Eu vi o código assim:
lockMutex(&mutex);
int rval;
if (...)
{
...
rval = foo();
}
else
{
...
rval = bar();
}
unlockMutex(&mutex);
return rval;
Sendo o desenvolvedor brilhante e brilhante de OO C ++, eu imediatamente chamei-os pelos riscos de bug que eles tinham ao bloquear e desbloquear mutexes manualmente, em vez de usar RAII . Eu insisti que isso era melhor:
MutexLocker lock(mutex);
if (...)
{
...
return foo();
}
else
{
...
return bar();
}
Muito mais simples e mais seguro, né ?! Por que os desenvolvedores precisam lembrar de desbloquear seus mutexes em todo o caminho do fluxo de controle quando o compilador pode fazer isso por você!
Bem, o que eu descobri mais tarde foi que havia uma razão processual para isso. Tivemos que confirmar que, sim, de fato, o software funcionava corretamente e havia uma lista finita de ferramentas que tínhamos permissão de usar. Minha abordagem pode ter sido melhor em um ambiente diferente, mas no ambiente em que eu estava trabalhando, minha abordagem multiplicaria facilmente a quantidade de trabalho envolvida na verificação do algoritmo dez vezes porque eu acabei de trazer um conceito C ++ de RAII para uma seção de código isso estava sendo mantido em padrões que eram realmente mais receptivos ao pensamento de estilo C.
Então, o que parecia ser um estilo de codificação ruim, absolutamente perigoso para mim, foi realmente bem pensado e minha "boa" solução era na verdade a solução perigosa que causaria problemas no futuro.
Então pergunte ao redor. Há certamente um desenvolvedor sênior que pode trabalhar com você para entender por que eles fazem isso dessa maneira. Ou existe um desenvolvedor sênior que pode ajudá-lo a entender os custos e benefícios de um refatorador nesta parte do código. De qualquer maneira, pergunte ao redor!