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

102

Estou trabalhando no meu trabalho há cerca de um ano. Eu principalmente trabalho em nossa interface GUI, que usa métodos de um backend C, mas eu geralmente não tenho que lidar com eles, exceto para os valores de retorno. Nossa GUI é estruturada razoavelmente, dadas nossas limitações.

Recebi a tarefa de adicionar uma função à parte da linha de comando do programa. A maioria dessas funções tem 300 linhas de comprimento e é difícil de usar. Eu estou tentando reunir partes deles para obter informações específicas de alarme, e estou tendo problemas para manter a organização. Eu sei que estou tornando meu teste mais complicado, fazendo isso em uma única função longa.

Devo apenas manter tudo em uma função enorme de acordo com o estilo das funções existentes ou encapsular os alarmes em suas próprias funções?

Não tenho certeza se é apropriado contrariar as convenções de codificação atuais ou se devo apenas morder a bala e tornar o código um pouco mais confuso para mim mesmo.

Em resumo, estou comparando

showAlarms(){
    // tons of code
}

contra

showAlarms(){
   alarm1();
   alarm2();
   return;
}

alarm1(){
    ...
    printf(...);
    return;
}

EDIT: Obrigado pelo conselho todo mundo, eu decidi que eu vou projetar o meu código fatorado e, em seguida, perguntar o que eles querem, e se eles querem tudo em um só posso cortar do meu código fatorado e transformá-lo de volta para uma grande função. Isso deve me permitir escrevê-lo e testá-lo mais facilmente, mesmo que eles queiram todo o código em uma única definição.

ATUALIZAÇÃO: Eles acabaram sendo felizes com o código informado e mais de uma pessoa me agradeceu por estabelecer esse precedente.

    
por Justin 12.12.2016 / 22:38
fonte

10 respostas

101

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!

    
por 13.12.2016 / 18:27
fonte
84
Honestamente, você acredita que ter funções difíceis de usar, com 300 linhas, é apenas uma questão de estilo? Então, seguindo o mau exemplo poderia manter o programa geral em um estado melhor por causa da consistência? Eu acho que você não acredita, senão você não teria feito essa pergunta aqui.

Meu palpite é que essas funções são tão longas porque em nossos negócios há muitos programadores medíocres que apenas empilham recursos sobre recursos, sem se importar com legibilidade, qualidade de código, nomeação adequada, testes de unidade, refatoração e nunca aprenderam crie abstrações adequadas. Você tem que decidir por si mesmo se você quer seguir aquele rebanho, ou se você quer ser um programador melhor.

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 .

    
por 12.12.2016 / 23:00
fonte
42

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.

    
por 12.12.2016 / 23:14
fonte
25

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!

    
por 13.12.2016 / 04:03
fonte
6

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.

    
por 12.12.2016 / 22:59
fonte
5

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:

Comece pequeno. Pergunte ao redor e descubra se alguém mais favorece funções menores. Melhor ainda bisbilhotar a base de código e ver se você consegue descobrir quem escreve os menores (você pode achar que o código mais feio é o mais antigo e os codificadores atuais estão escrevendo um código melhor). Fale com eles sobre isso e veja se você tem um aliado. Pergunte se eles conhecem alguém que se sinta do mesmo jeito. Pergunte se eles conhecem alguém que odeia pequenas funções.

Reúna esse pequeno grupo e fale sobre como fazer mudanças. Mostre a eles o tipo de código que você gostaria de escrever. Certifique-se de que eles possam lê-lo. Tome quaisquer objeções a sério. Faça as alterações. Obtenha seu código aprovado. Você agora tem o poder de uma reunião atrás de você. Mais alguns deles e você pode produzir um documento de uma página que aceita explicitamente o novo estilo que você introduziu.

Reuniões são coisas surpreendentemente poderosas. Eles podem produzir influência. Clout é o que você vai usar para lutar contra aqueles que se opõem a este movimento. E é isso que isso é neste momento. Um movimento. Você está lutando pelo direito de melhorar o status quo. As pessoas temem a mudança. Você precisará falar docemente, persuadir e cutucar. Mas com um pouco de sorte você vai se transformar em ser aceito.

    
por 13.12.2016 / 02:51
fonte
3

À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.

Independentemente da bagunça, eu entendo que é tentador limpá-lo. mas no mundo dos negócios você nem sempre tem a chance de refatorar código.

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.

    
por 13.12.2016 / 02:11
fonte
3

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.

    
por 13.12.2016 / 03:44
fonte
3

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.

    
por 13.12.2016 / 11:12
fonte
1

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.

    
por 12.12.2016 / 23:05
fonte