Devo seguir um estilo de código ruim apenas para seguir as convenções estabelecidas no meu local de trabalho?

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!

Adendo, devido aos comentários: "300 linhas" e "difícil de usar" são strongs indicações IMHO para código ruim. Para minha experiência, é muito improvável que exista alguma "razão técnica oculta" para que tal código não possa ser implementado de maneira mais legível, comparável ao exemplo da resposta de Cort Ammon. No entanto, eu concordo com Cort, você deve discutir isso com os responsáveis na equipe - não para encontrar razões obscuras porque o código ou esse "tipo de estilo" não pode ser alterado, mas para descobrir como o código pode ser refatorado com segurança sem quebrar coisas .

Não.

No livro Programador Pragmático , o autor fala sobre o Teoria das janelas quebradas .

Este estado teórico:

Consider a building with a few broken windows. If the windows are not repaired, the tendency is for vandals to break a few more windows. Eventually, they may even break into the building, and if it's unoccupied, perhaps become squatters or light fires inside.

Or consider a pavement. Some litter accumulates. Soon, more litter accumulates. Eventually, people even start leaving bags of refuse from take-out restaurants there or even break into cars.

No livro, o autor escreve um paralelo entre essa teoria e o código. Uma vez que você encontrou um código como esse, pare e se questione sobre essa mesma pergunta.

E a resposta é: Não.

Quando você sair dessa janela quebrada - no nosso caso, código ruim - isso criará o efeito de que todos deixarão janelas quebradas para trás.

E um dia o código entrará em colapso.

Dê uma cópia do Código limpo e Clean Coder para todos.

E enquanto você estiver no assunto, uma cópia do TDD também é boa.

Sim, vá em frente. Estrutura! = Estilo

Você está falando de estrutura, não de estilo. Diretrizes de estilo não (geralmente) prescrevem estrutura, uma vez que a estrutura é geralmente escolhida por sua adequação a um problema específico, e não pela adequação a uma organização.

Tenha cuidado

Basta ter certeza de que você não está causando consequências negativas em outras áreas que podem não ter ocorrido a você. Por exemplo,

• Verifique se você não está complicando os diffs nem as combinações de código, pois você eliminou qualquer semelhança com o código existente.
• Certifique-se de que os fluxos de exceções sejam agrupados corretamente e que os rastreamentos de pilha não sejam poluídos com uma enorme pilha de tolices ilegíveis.
• Verifique se você não está expondo acidentalmente pontos de entrada públicos que poderiam causar problemas se chamados diretamente (não os coloque no mapa e / ou não os exporte).
• Não sobrecarregue o espaço de nomes global, por ex. se todas as suas funções menores exigirem algum tipo de contexto global que foi anteriormente declarado no escopo da função local.
• Assista a todos os logs e pergunte a si mesmo se você estava na equipe de suporte se os logs gerados pelo seu código ficassem confusos quando vistos interligados com os logs de qualquer código que você não toca.
• Certifique-se de que faça aderir ao estilo existente, por ex. mesmo que eles estejam usando a notação húngara da velha escola e isso faça seus olhos sangrarem, fique consistente com a base geral de códigos. A única coisa mais dolorosa do que ler a notação húngara é ler código que usa uma dúzia de diferentes tipos de notação, dependendo de quem escreveu o quê.

Seja gentil

Lembre-se de que você faz parte de uma equipe e, embora um código bom seja importante, também é muito importante que os membros de sua equipe consigam manter as coisas que você escreveu quando sai de férias. Tente manter um fluxo que faça sentido para as pessoas que estão acostumadas com o estilo antigo. Só porque você é o cara mais esperto da sala não significa que você deva falar acima da cabeça de todos!

Não vejo isso como uma convenção de código. Eu vejo isso como alguém que não entende como escrever código sustentável que seja fácil de entender. Eu dividiria seu código em diferentes funções conforme você sugerisse e instruísse sua equipe sobre os benefícios de fazer isso enquanto tentava entender por que eles acham que as funções de 300 linhas são aceitáveis. Eu ficaria muito interessado em ouvir o raciocínio deles.

A resposta está na revisão de código.

A verdadeira questão é se você entregar um código bem consignado, você será o único disposto a trabalhar com ele?

Eu, como a maioria das pessoas aqui, acredito que 300 funções de linha são uma abominação. No entanto, levar o Windex para um aterro não vai fazer muito bem. O problema não é o código, são os codificadores.

Apenas estar certo não é suficiente. Você precisa vender pessoas nesse estilo. Pelo menos ao lê-lo. Se você não acabar como esse pobre rapaz:

Às vezes você tem que ir com o fluxo.

Como você disse, você foi encarregado de implementar uma função em uma base de código existente.

Eu diria apenas faça o que lhe foi pedido e siga em frente.

Se você acha que vale a pena refatorar ou reescrever, é necessário discuti-lo com a equipe.

Antes de declarar que as práticas são ruins, eu primeiro daria um passo em direção ao entendimento da razão para os grandes métodos e outras práticas que podem parecer ruins.

Em seguida, você precisa garantir que a cobertura de teste seja bastante alta ou muito alta (até onde você pode fazer sem grandes refatorações). Se não for, eu trabalharia para tornar a cobertura realmente alta, mesmo que você não tenha escrito o código. Isso ajuda a construir o rapport e a nova equipe de vocês levará você mais a sério.

Depois de ter essas bases cobertas, ninguém no seu perfeito juízo iria desafiá-lo. Como um item bônus, faça alguns micro-benchmarking e isso realmente adicionará ao seu caso.

Muitas vezes, a maneira como você fala isso vai longe no sentido de mudar a cultura do código. Lidere pelo exemplo. Ou melhor ainda, espere por um pedaço de código que você possa escrever - refatorar e testar a unidade e viola - você será ouvido.

Este tipo de pergunta é basicamente " por favor leia meus companheiros de equipe ". Pessoas aleatórias na internet não podem fazer isso, então todas as respostas que você obterá são apenas opiniões pessoais sobre estilo de codificação. O consenso é que métodos mais curtos são preferíveis, mas parece que você já pensa assim, então não há necessidade de reafirmar isso.

Assim, a base de código atual parece usar um estilo de codificação diferente daquele que você prefere. O que você deveria fazer? Primeiro você precisa descobrir:

1. Essa é uma decisão de design deliberada apoiada por sua equipe atual?
2. Eles querem que você siga esse estilo?

Existe apenas uma maneira de descobrir. Peça .

Pode haver vários motivos para ter funções longas. Pode ser porque a equipe acredita que funções longas são melhores que várias funções curtas. Também pode ser porque é um código herdado, e a equipe prefere que o novo código siga um design mais limpo. Então, a escolha qualquer pode colocá-lo em problemas como desenvolvedor, se você não conversar com a equipe e entender o raciocínio deles.

Existem diferentes níveis de "estilo".

Em um nível, geralmente parte das convenções de codificação, isso significa onde colocar espaços em branco, linhas em branco, colchetes e como nomear as coisas (maiúsculas e minúsculas, sublinhados, etc.).

Em outro nível é o modelo de programação, às vezes coisas como evitar estática, ou usar interfaces sobre classes abstratas, como expor dependências, talvez até mesmo evitando alguns recursos de linguagem esotérica.

Depois, há as bibliotecas e estruturas em uso pelo projeto.

Às vezes, haverá um limite máximo no tamanho da função. Mas raramente há um limite mínimo! Então, você deve descobrir quais dessas coisas são importantes e tentar respeitar isso.

Você precisa descobrir se a equipe é adversa para refatorar o código existente, o que deve ser feito independentemente de adicionar novos códigos quando possível.

No entanto, mesmo que eles não queiram refatorar o código existente, você poderá introduzir algumas camadas em abstrações para o novo código que você adicionar, o que significa que com o tempo você pode desenvolver uma base de código melhor e talvez migrar código antigo como a manutenção dele exige.