O estilo de codificação nas organizações é opcional?

Este documento de estilo de programação possui uma regra geral, que diz:

As regras podem ser violadas se houver fortes objeções pessoais contra elas.

Isso colide com o que estou pensando e há muitos artigos dizendo que o estilo de codificação é realmente importante. Por exemplo, isso diz:

Um documento de padrões de codificação informa aos desenvolvedores como eles devem escrever seu código. Em vez de cada desenvolvedor codificar em seu próprio estilo preferido, eles escreverão todo o código nos padrões descritos no documento. Isso garante que um projeto grande seja codificado em um estilo consistente - as partes não são escritas de maneira diferente por programadores diferentes. Essa solução não apenas facilita a compreensão do código, mas também garante que qualquer desenvolvedor que observe o código saiba o que esperar em todo o aplicativo.

Então, estou entendendo mal algo deste documento e a citação na parte superior desta pergunta? As pessoas podem realmente simplesmente ignorar o estilo de codificação?

Talvez eu não tenha sido claro o suficiente, então, com esta edição, vou esclarecer um pouco.

Estou escrevendo o documento de estilo de codificação para nossa equipe e quero verificar o estilo usando alguns analisadores estáticos. Se falhar, Jenkins enviará emails. E quero falhar na revisão do código, se o estilo não corresponder. Isso claramente colide com a primeira citação.

Mas então, se a citação estiver correta, qual é a utilidade do documento de estilo de codificação, se alguém puder fazer o que quiser?

Tanto quanto posso dizer, a afirmação que o confundiu é um compromisso pragmático feito para que as diretrizes atendam ao maior público possível. Dependendo do seu contexto específico (mais sobre isso abaixo), você pode ter a opção de ajustá-lo e fazer um uso mais eficiente das diretrizes.

Veja bem, as diretrizes se referem a "fortes objeções pessoais" como um meio de justificar a violação. Tais objeções não são algo a ser ignorado levianamente, principalmente se forem provenientes de desenvolvedores experientes.

Essas objeções podem estar erradas, lembre-se, mas (e isso é MUITO GRANDE), mas também podem indicar que uma regra específica está errada - geralmente ou no contexto específico do projeto (um exemplo de desajuste das regras é um requisito para fornecer registro detalhado no código crítico de desempenho).

Penso que qualquer guia de estilo sensato deve levar em conta o exposto acima e tentar acomodar uma possível necessidade de se ajustar. Agora, se o guia que confundiu você foi direcionado apenas para equipes maduras com processos e ambiente eficientes e suaves, ele poderia ser declarado com muito menos ambiguidade, por exemplo:

As regras devem ser seguidas estritamente, a menos que um desafio seja levantado contra elas - nesse caso, a regra contestada deve ser ignorada até que isso seja resolvido - rejeitando o desafio ou aceitando-o e ajustando as regras para que se ajustem.

Você pode gostar do que foi dito acima e desejar que seja assim em todos os lugares, para todos, mas observe mais de perto a parte "desafio é levantado / fique ignorado / ajuste" e pergunte a si mesmo como ele pode ser implementado. Pergunte a si mesmo quanto tempo pode demorar, dependendo do projeto e da equipe. Se demorar uma hora, isso é aceitável? E se demorar um dia, uma semana ou ... um mês?

Veja bem, essa abordagem de desafiar e ignorar até resolver pode abrir uma grande porta para abuso se for apresentada como um guia para qualquer projeto. "Sim, sim, ouvimos você, vamos fazê-lo como o guia diz. Primeiro, preencha este formulário de desafio e obtenha as aprovações de CEO / CFO / CTO; espere que isso leve uma semana ou duas. Depois disso, aguarde até atualizarmos nossas verificações de código ; isso pode levar mais uma ou duas semanas. Enquanto isso, verifique se o código crítico de desempenho vomita instruções de log formatadas adequadamente sobre cada movimento do registro ".

Não consigo ler a mente dos autores do guia, mas parece razoável supor que eles queriam evitar usá-lo para justificar uma bagunça, conforme descrito acima. Nessa perspectiva, é mais seguro afirmar claramente que o guia não assume nenhuma aplicação - dessa maneira, por mais desajeitado, ainda permite que seja utilizável para uma ampla variedade de equipes e projetos arbitrariamente. Provavelmente, existe uma expectativa de que uma oferta tão ampla deixe equipes mais maduras e eficientes a oportunidade de reduzi-la razoavelmente, sem prejudicar a produtividade do desenvolvedor.

Aplicado ao seu caso específico, escrevendo o documento de estilo de codificação para sua equipe e falhando na revisão do código, se o estilo não corresponder. Acho que você precisa descobrir quanto tempo levará para os desenvolvedores desafiarem uma regra específica, ignorá-la, resolvido e alterou ou recuperou, dependendo da resolução.

Se você descobrir uma maneira de fazer esse processo funcionar sem introduzir muitos obstáculos no seu fluxo de trabalho de desenvolvimento, vale a pena considerar uma abordagem formal / fácil de controlar / desafiar, em vez do caótico "violar se você chorar alto o suficiente".

Como observação, gostaria de abordar o que você escreveu em outro comentário : "Suponha que o estilo de codificação seja ideal e, se não for o caso, etc."

Esta é uma suposição perigosa, realmente. Eu quebrei meu nariz nele (duas vezes! Em um único projeto! Onde tive uma vasta experiência e imaginei que sabia tudo sobre isso, entenda) e recomendo fortemente que você o deixe cair. É mais seguro supor que o guia de estilo possa ter erros e se esforçar para pensar no que fazer caso esses erros sejam descobertos.

Permitir que as pessoas ignorem os estilos de codificação devido à preferência pessoal é uma má ideia.

A citação na sua pergunta parece permitir que qualquer desenvolvedor simplesmente diga "Não vou usar esse estilo porque não gosto".

Isso vai contra o ponto principal, que está levando todos da equipe a fazer as coisas da mesma maneira para obter consistência e legibilidade.

Concordo que um documento de estilo com essa afirmação provavelmente não faz sentido.

No entanto, é aconselhável alguma flexibilidade no cumprimento das diretrizes de estilo:

• Seguir servilmente uma diretriz pode impedir a melhor maneira de escrever uma parte específica do código . Os desenvolvedores devem poder ignorar as diretrizes e defender que o que eles fizeram é a melhor e mais legível maneira de realizar algo nesse caso.
• Trabalhar com código legado pode exigir flexibilidade. Provavelmente, não é um bom uso do seu tempo reestilizar uma grande base de código existente. Se você reescrever uma seção específica significativamente, poderá reformatá-la no estilo preferido. No entanto, se você fizer apenas uma pequena alteração, talvez seja melhor usar o estilo existente do código.
• Analisar cada pequena violação do guia de estilo não é um bom uso do tempo. A revisão do código é um bom momento para destacar qualquer código que esteja significativamente fora de linha com o estilo da equipe. No entanto, pegar e consertar pequenos "erros" de estilo provavelmente se tornará um trabalho ocupado, focado na coisa errada. Claro, falhe na revisão do código se o estilo foi descaradamente ignorado. Mas eu não gosto da idéia de executar um analisador e apontar todos os parênteses ou recuos extraviados, não importa falhar com alguém nessa base.

Conclusão: permita flexibilidade ao seguir as diretrizes de estilo, a fim de melhor atender às necessidades de sua equipe - mas não por razões arbitrárias, como preferência pessoal.

Existem estilos de codificação e guias de estilo para ajudar a tornar o código mais legível. E existe legibilidade para ajudar na complexidade.

Portanto, em última análise, a violação ou não (eu o chamaria de adaptação) do estilo de codificação para atender às suas necessidades organizacionais se resume a quanto isso ajuda a tornar as coisas compreensíveis.

Lembre-se de que tudo, e enfatizo, TUDO, da programação OO aos paradigmas funcionais, a vários modelos de concorrência, existe pelo único motivo de ajudar as pessoas a lidar com a complexidade.

Qualquer tolo pode escrever um código que um computador possa entender. Bons programadores escrevem código que os humanos podem entender. - Martin Fowler, 2008

O estilo de codificação nas organizações é opcional?

As organizações optam por ter estilos de codificação - não há necessidade de obtê-lo em primeiro lugar.

Portanto, a citação que você está lendo aborda o maior problema que eu vejo em relação à codificação de "estilo" e verdadeiros superstar "hackers" - você traz um novo cara a bordo e ele escreve um código que derruba zumbis e faz com que seus antigos servidores gritem rapidamente. .. mas o estilo de codificação dele é diferente do seu "estilo organizacional aceito". Ele se recusa a mudar e o processo para fazer com que todos se conformem com seu estilo particular será demorado e caro. O que agora?

A maioria dos super hackers que conheço vem com egos tão grandes quanto suas habilidades, e eles querem que a organização se adapte a eles , e não o contrário. Portanto, talvez seu padrão de estilo de codificação deva ser mais como uma diretriz de estilo de codificação, para que você possa permitir que esse hacker assassino continue escrevendo códigos incrivelmente rápidos e surpreendentes com algum desvio de estilo, mas certifique-se de que todos os outros entendam isso até atingirem seu hacker épico status, eles precisam seguir as regras (ou até ajudar a limpar depois dele).

Obviamente, esse é um pesadelo para a gerência, mas gerenciar o pessoal de tecnologia em geral é como pastorear gatos de qualquer maneira. Portanto, a maioria das empresas possui "diretrizes de estilo" e não "padrões de estilo". E as construções não falham e as revisões de código não falham automaticamente devido a violações de estilo em todas as empresas. Você decide o problema de gerenciamento que deseja - permita hackers de superestrelas e tenha "diretrizes" ou perca as superestrelas e tenha um estilo de código mais consistente.

Então, estou entendendo mal algo deste documento e a citação na parte superior desta pergunta? As pessoas podem realmente simplesmente ignorar o estilo de codificação?

Depende.

O local em que estou atualmente não tem um guia de estilo e não é grande coisa. Existem algumas pequenas variações entre os programadores, mas não tanto quanto impactar a legibilidade, a descoberta ou a consistência de maneira significativa. E temos um grupo grande o suficiente e uma cultura forte o suficiente para garantir que qualquer novo membro da equipe caia na linha (ou então).

Nas empresas anteriores, estávamos crescendo rapidamente e tínhamos pessoas que não estavam familiarizadas com o idioma e seus idiomas. Naquela empresa, o afluxo de pessoas significava que não havia uma cultura que reforçasse a boa escrita. E as pessoas novas no idioma significavam que havia muitas coisas para ajustar. Verificadores de estilo automatizados eram a maneira mais eficiente de fazer os ajustes, e um guia por escrito real era a melhor maneira de treinar as novas pessoas em nossas expectativas.

Pessoalmente, não ligo muito para os guias de estilo e ainda menos para a imposição automatizada de estilos. Se a pessoa não consegue nem entender os idiomas básicos, por que você os está empregando como programador? E se eles são um jogador de equipe tão ruim que escrevem continuamente códigos que outras pessoas acham difíceis de trabalhar, por que você os está empregando?

Isso é mais uma manobra psicológica, em vez de uma interpretação literal de como melhor gerenciar os estilos de codificação. Isso torna a equipe / empresa / gerente / líder menos autoritária. Eu focaria mais em exceções situacionais em vez de pessoais. Independentemente do documento de codificação, o objetivo é facilitar a leitura. Código confuso deve ser endereçado e alterado, se necessário. Existem muitas ferramentas para cuidar das pequenas coisas tediosas, então use-as.

Há exceções para todas as regras. Dê às pessoas "um pouco" de espaço de manobra. Quanto menos todos estiverem envolvidos em aceitar as regras de estilo de codificação (Bem-vindo, cara novo), mais eles tenderão a querer revidar. Muitas coisas são em preto e branco, mas algumas estão abertas à interpretação.

O objetivo deve ser envolver todos no espírito das diretrizes de codificação, em vez de brigar por cada pequeno detalhe e interpretação.

Sim, chegará um momento em que o documento sobre o estilo de codificação não fará sentido e os desenvolvedores profissionais e adultos deverão saber a diferença.

Com base em suas edições, seu objetivo é o objetivo certo.

Há muitos benefícios em usar um guia de estilo, mas os dois mais importantes na minha opinião são a legibilidade do código entre os membros da equipe e a falta de confirmações "tolas" (como apenas espaço em branco ou linhas extras e similares).

Para atingir seu objetivo, o guia de estilo escolhido (ou criado) deve ser simples e fácil de aderir. Tente realmente se concentrar no que você precisa. Ninguém gosta de ter que voltar e reescrever uma enorme amostra de código apenas para deixar um linter feliz. Mas ainda pode haver algum benefício.

Verifique se os membros da sua equipe aprovam o guia de estilo. Você vai segurá-los, certifique-se de que eles concordem ou será uma luta eterna.

Certifique-se de que as violações de estilo sejam um "aviso" e não uma "falha"; deixe um ser humano decidir se a violação atende a uma falha. A razão para isso é simples. Eu acredito em um fluxo de trabalho simples. Se em algum lugar da fase "teste" ocorrer uma "falha", não será possível enviar para a produção. Eu uso é como uma segurança. Até hot fixes precisam passar por uma fase de teste (embora seja mais curta). Você pode realmente dizer que não enviará essa correção crítica de bug à produção porque alguém usou um "em vez de um?" Que tal usar um loop for em vez de um each? E se um loop for tiver alguma melhoria em relação a cada um? são decisões que uma máquina (linter) não pode tomar; portanto, certifique-se de ter um ser humano, julgue o aviso e não a falha da máquina.

Quanto a ignorar o Guia de estilo, você terá que julgar isso caso a caso. Verifique se o "desvio" tem um motivo real. Eles aparecerão. O trabalho dos revisores é garantir que haja um bom motivo para o desvio e não um trivial.

Eu acho que a música humorística aqui é que, se a sabedoria aceita é que os padrões de codificação estão incorretos ou incompletos, é o menor dos dois males a serem seguidos se os desenvolvedores estiverem de acordo geral, em vez de passar pelo árduo processo de obter o código. documento alterado e revisto.

Também deve-se observar que as políticas de aplicação padrão de código do passado não são tipicamente do jeito que as coisas são feitas agora.

Antigamente, você simplesmente segurava o tomo no final da mesa dos desenvolvedores e citava o capítulo e o verso por que seu código viola a seção 34.5.5767.

Agora, temos ferramentas de análise estática de códigos e de documentação automática que levam muito do trabalho árduo dos padrões de código.

Na falta de tudo isso, você ainda pode devolvê-lo ao desenvolvedor, elevá-lo em uma revisão de código ou apenas alterá-lo, se desejar.

Sua pergunta gira em torno da reconciliação das duas citações. Eu acho que o treecoder escreveu responde à sua pergunta em geral. Ele representa seu princípio norteador nas diretrizes de estilo de redação.

Mais especificamente, como você é responsável por definir as diretrizes de estilo de codificação (essa é minha suposição, pois você é o autor do documento), você decide o que é opcional ou não e em que grau permitirá flexibilidade no estilo pessoal de seu equipe. Você receberá feedback sempre que necessário. Mas uma vez que as diretrizes estejam em vigor, atenha-se a elas.

Portanto, você pode reconciliar as duas aparentes contradições como esta:

Pense na primeira citação como endereçada a você como tomadora de decisões de estilo, antes que o documento de diretrizes seja concluído. Se um determinado padrão de estilo não funcionar para sua equipe, isso será considerado uma "forte objeção pessoal", e suas diretrizes o refletirão.

Pense na segunda cotação como endereçada à sua equipe, depois que o documento for concluído. Depois de definir as diretrizes para a equipe e o documento ser escrito, é importante que todos os desenvolvedores de sua equipe sigam as diretrizes de estilo.

Não importa muito o estilo de codificação que as pessoas têm, desde que tenham um estilo de codificação. Se uma empresa insistir em um estilo de codificação, ela pisará pesadamente em cerca de 49% de seus desenvolvedores.

O problema é que um grande número de desenvolvedores não se importa muito em adaptar seu estilo de codificação a algum padrão predominante em uma empresa, mas se importa muito em ser informado por aqueles que são melhores (ou apenas se preocupam mais com) a política da empresa.

Isso significa que criar um padrão de estilo de codificação pode ser uma enorme perda de tempo, uma fonte de argumentos sem fim, a causa de um ressentimento infinito e, em geral, uma enorme perda de tempo e energia.

Eu luto com as diretrizes de estilo de código há anos, como muitos outros têm neste fórum. Isso inclui os dois guias de estilo de luta que considero abomináveis, e a tentativa de incentivar outras pessoas a usarem guias de estilo para controlar seu estilo, para que possa ser mais legível como um todo.

A corporação se beneficia de um padrão de codificação comum. Há muitas coisas importantes a considerar ao desenvolver software para uma empresa, como a forma como treinamos novos desenvolvedores para pegar o código da geração anterior. Quando você está escrevendo um código, nem sempre pensa nisso. De fato, muitos codificadores optam por nem sequer considerar como os outros podem querer abordar o código 5 ou 10 anos depois de terem saído. Um guia de estilo de codificação é uma maneira de uma empresa fornecer foco para essas metas de 5 e 10 anos, facilitando o trabalho dos desenvolvedores no esquema mais amplo.

Por outro lado, os guias de estilo de codificação são notoriamente imperfeitos, porque não é possível desenvolver um estilo de codificação perfeito e anotá-lo. Na verdade, você começa a encontrar casos engraçados em que provas matemáticas começam a falhar se você tentar torná-lo perfeito. Portanto, sabemos que os guias de estilo de codificação são imperfeitos. Eles podem não se concentrar perfeitamente no que precisamos de 5 a 10 anos depois.

Se "aplicássemos" um estilo de codificação, estaríamos sacrificando valor agora por valor mais tarde. Isso seria chamado de "investimento" se pudéssemos ter certeza de que obteríamos um retorno de nossos esforços, mas qualquer desenvolvedor que tenha trabalhado com um guia de estilo de codificação mal escrito pode atestar que esses ganhos de "legibilidade" são pagos com muito carinho pela distração dos desenvolvedores. longe de seu código. Na minha experiência, há apenas um número muito pequeno de casos em que os estilos de codificação impostos têm mérito, normalmente em software para clientes exclusivamente glaciais, onde o software pode ser usado por 30 ou 40 anos!

Em vez disso, acho mais eficaz tratar um guia de estilo de codificação como um manifesto: "É isso que acreditamos que o melhor estilo de codificação seja para o nosso grupo". É um monte de pensamentos fluidos documentados em palavras. A palavra "acreditar" é importante: se as crenças mudam, os guias de estilo de codificação devem mudar com ela.

É aí que entra a citação de "fortes objeções pessoais". No que eu chamaria de mundo "perfeito", você escreve o código que achar melhor e vive com as consequências. Muitas vezes gostamos de ignorar as consequências "suaves" quando estamos programando, mas, neste caso, elas são importantes. Não tenho nenhum problema com você escrevendo em seu próprio estilo, se você não se importa que eu nunca lhe dê algo importante e duradouro para se desenvolver.

Pense em todo o sistema como um campo de golfe. O estilo de codificação abre o caminho fácil pelo fairway. Se você se mantiver no padrão de codificação, garantiremos que a vida seja a mais fácil possível. Quanto mais você se esforça, usando seus próprios padrões de codificação, mais precisará provar seu valor para a equipe.

Se eu for na segunda-feira de manhã, para descobrir que você passou o fim de semana inteiro resolvendo um problema que estamos preocupados há um ano, e você fez isso em seu próprio padrão de codificação "especial", não vou dizer para você consertá-lo. Vou dizer para você tomar um banho. Se o seu padrão de codificação "especial" for excepcionalmente "especial", posso sugerir que um desenvolvedor iniciante "revise" o código para espalhar o conhecimento de como seu código funciona e mencione de imediato que, se algo parecer difícil de ler, ele deve arrumá-lo. Você forneceu um valor suficiente para a empresa naquele fim de semana que vale a pena nem mencionar as violações flagrantes dos padrões de codificação que cometeu.

É claro que existem fora dessa área a metáfora do golfe. Se eu pedir para você executar alguma tarefa de classificação e arquivo, talvez adicionando novos campos a algum formulário, e você decidir aproveitar a oportunidade para refatorar todo o código de preenchimento de formulário para se adequar ao seu estilo específico, usando vários caracteres obscuros, como definir macros e alguma terrível técnica de metaprogramação de modelos que você acabou de aprender com a troca de pilhas, será solicitado a voltar e corrigi-la. Você escolheu agir, essas são as consequências.

( Isenção de responsabilidade: eu escrevi totalmente essa implementação is_base_ofpara resolver uma tarefa servil e ganhei todo o inferno que recebi dos desenvolvedores seniores. Digo que valeu a pena. Ainda sinto uma risada alegre toda vez que veja como esse padrão une 7 partes não relacionadas da especificação C ++ para fazer algo incrível. Considere isso, seus desenvolvedores seniores! É isso que você consegue proibir boostneste projeto em particular! )

Best parece usar o formatador de código automatizado que é um recurso interno de quase qualquer IDE descendente e deve existir para quase qualquer linguagem de programação mais ou menos difundida. Isso elimina silenciosamente muito trabalho desnecessário e muito atrito durante as revisões de código.

É totalmente razoável exigir que todos os desenvolvedores desenvolvam o hábito de aplicar o formatador à seção recém-criada do código.

O pior que você pode fazer é exigir algum estilo de codificação personalizado que o formatador de código existente não suporta.

Em casos relativamente raros, algumas seções podem ser formatadas de maneira diferente, se o formatador fizer isso de maneira horrível, mas geralmente é melhor ajustar o formatador para que todos possam formatar melhor.

Pode haver algumas regras úteis que o formatador não pode suportar (como nomear variáveis, por exemplo), mas se apenas essas permanecerem, elas são relativamente fáceis de seguir.

Solução real (não apenas filosofia)

Permita que os comentários do código substituam o fiapo e compile as listas desses comentários, se desejar (como é feito com os comentários frequentes)

Dê a seus desenvolvedores a capacidade de trabalhar fora da convenção explicitamente e com razão - e durante as revisões de código feitas por humanos, elas podem ser examinadas conforme necessário.