Por que o tio Bob sugere que os padrões de codificação não devam ser anotados se você pode evitá-lo?

145

Enquanto eu lia essa pergunta , a resposta mais votada citou o tio Bob nos padrões de codificação , mas fiquei confuso com esta dica:

  1. Não as anote se puder evitá-la. Em vez disso, deixe o código ser o modo como os padrões são capturados.

Isso ricocheteou no meu cérebro, mas não consegui encontrar um lugar para ficar. Se uma nova pessoa se juntar à equipe ou os padrões de codificação mudarem, não haveria confusão de informações?

Por que não devo escrever um padrão de codificação?

Legal preguiçoso
fonte
47
Hmm. Estou tentando imaginar como isso funcionaria em uma grande empresa multinacional, com centenas de desenvolvedores e uma base de código de décadas.
Matthew James Briggs
31
@MatthewJamesBriggs: funciona tão bem quanto um padrão anotado que a maioria dos desenvolvedores ignora, ou que tinha um conteúdo diferente no momento em que o código foi escrito inicialmente.
Doc Brown
7
@MatthewJamesBriggs: concordou. O guia de estilo deve conter informações suficientes para reconhecer as convenções anteriores que agora estão obsoletas; caso contrário, a cultura de "copiar o estilo existente" encontrará um horror de 10 anos para ressuscitar. Além disso, quando cliques acidentalmente se formam e usam espécimes diferentes e incompatíveis para deduzir o estilo oficial, o guia de estilo escrito diz qual deles está certo (ou idealmente, impede a formação de camarilhas em primeiro lugar). E se algumas de suas centenas de desenvolvedores não leem documentos, em uma grande empresa, você pode simplesmente demiti-los por muppetry bruto.
Steve Jessop
14
Embora seja justo, Bob também disse que você não deveria ter um padrão de codificação para toda a empresa, escrito ou não. Em vez disso, cada equipe / grupo deve desenvolver a sua própria.
Steve Jessop 24/05
37
Em vez de escrever um documento que ninguém lerá, use um linter que imponha o código de uma certa maneira. Se faz parte do seu processo de desenvolvimento, é inevitável.
Seiyria 24/05

Respostas:

256

Há algumas razões.

  1. Ninguém lê documentação.
  2. Ninguém segue a documentação, mesmo que a leia.
  3. Ninguém atualiza a documentação, mesmo que a leia e a siga.
  4. Escrever uma lista de práticas é muito menos eficaz do que criar uma cultura.

Os padrões de codificação não são sobre o que as pessoas devem fazer, mas sobre o que realmente fazem. Quando as pessoas se desviam dos padrões, isso deve ser percebido e alterado por meio de um processo de revisão de código e / ou ferramentas automatizadas.

Lembre-se de que o objetivo principal dos padrões de codificação é facilitar nossa vida. Eles são um atalho para o nosso cérebro, para que possamos filtrar as coisas necessárias das coisas importantes. É muito melhor criar uma cultura de revisão para aplicar isso do que formalizá-la em um documento.

Stephen
fonte
11
E se você deseja impor as coisas, deve ter uma etapa do processo de compilação que as imponha, não um guia de estilo.
Wayne Werner
31
Você realmente não tem um documento padrão, mas apenas grita com as pessoas nas primeiras semanas em cada revisão de código? Parece que você basicamente esperaria que os iniciantes fizessem a engenharia reversa de seus guias de estilo de codificação. Ou isso é mais hipotético "Eu acho que é isso que ele quis dizer"? Agora, se isso é sobre ferramentas automáticas que aplicam essas regras - concordadas, isso é essencial. Mas não quero ter que descobrir laboriosamente as regras.
Voo
13
@Voo, por que você sente que precisa gritar durante uma revisão de código se surgir um problema?
Jaap
20
@ Jaap Eu pensei que a hipérbole era óbvia .. aparentemente não. Não, não gritando com as pessoas, mas dizendo a elas que elas precisam voltar e consertar todas as coisas que violaram porque não sabiam melhor.
Voo 25/05
5
@ Voo: você não precisa fazer "engenharia reversa de guias de estilo de codificação". As convenções devem ser aparentes ao analisar o código existente. Tudo o que não salta imediatamente nos olhos é incomum ou nem mesmo consertado. Caso haja regras realmente importantes sobre algo que raramente ocorre, pode valer a pena discuti-lo com os novos desenvolvedores, quando eles são os que precisam escrever esse código. A comunicação não pode ser superestimada.
Holger
112

Há outra interpretação. Não acredito que seja o que o tio Bob quis dizer, mas vale a pena considerar.

Não capture padrões de codificação em um documento. Capture-o no código, com um processo automatizado que verifica se os padrões estão sendo atendidos .

Não confie nas pessoas que fazem referência a um documento, mas, ao mesmo tempo, não confie nas pessoas que interpretam o código que já existe e identificam o que é convenção e o que é coincidência.

Incorpore algo como Checkstyle em sua compilação de confirmação. Isso pode impor regras básicas, como padrões de formatação e nomeação, e, em vez de gastar esforço mental ao considerar o estilo, tudo isso pode ser transferido para um processo idiota que é pelo menos garantido que é completo.

Se isso importa, defina estritamente o que você deseja e falhe se estiver errado.

Tom Johnson
fonte
6
Na verdade, suspeito que algo assim fosse pelo menos parte do raciocínio do tio Bob para a sugestão. Automatização de padrões de codificação vai ao lado automatizado de teste como uma forma útil de melhorar a qualidade, e tenho certeza de que Bob sabe que ...
Jules
10
Pode valer a pena mencionar a regra 6: After the first few iterations, get the team together to decide.com apenas a regra 3, parece que ele não está defendendo nenhum padrão de codificação, mas ao considerar todas as regras juntas, e acima de tudo, a # 6, parece que ele está realmente dizendo: "Não forçar um padrão de codificação a princípio. Deixe que ele se desenvolva organicamente e, depois de um tempo, sente-se com sua equipe para detalhar os detalhes ". O que é muito diferente de "Não formalize seu padrão de codificação" (que parece ser a essência de muitas respostas).
Shaz 24/05
Se você ler os itens, acho que descobrirá que isso certamente não é o que ele quis dizer, por exemplo, este aqui deveria lhe dizer uma coisa: 2. Deixe que eles sejam específicos da equipe e não da empresa.
Bill K
Observe que estou respondendo à pergunta "Por que não devo escrever um padrão de codificação" - não "O que o tio Bob quis dizer". Isso pode ser contrário ao título da pergunta, mas não ao seu espírito.
Tom Johnson
Observe que um sistema de formato de codificação automatizado que não fornece uma cláusula de escape (onde eu posso desativá-lo para uma seção de código) quase certamente será malware em algum momento.
Yakk 26/05
66

As pessoas ignoram o real objetivo de um documento de normas de codificação, que é resolver disputas .

A maioria das decisões no padrão de codificação terá apenas um efeito muito menor na legibilidade e na produtividade. Especialmente se você adota o estilo 'normal' para o idioma, e os designers de idiomas estão começando a perceber que isso deve fazer parte das especificações (por exemplo, Go).

Por serem tão triviais, os argumentos podem se aquecer e continuar indefinidamente, causando danos reais à produtividade e à coesão da equipe. Ou pode obscurecer seu histórico de alterações com a reformatação sem fim entre os estilos preferidos de duas ou mais pessoas.

Ter um padrão escrito encerra o argumento. Os gerentes podem apontar para ele e desviar a insatisfação em relação ao documento. Você pode discutir com um pedaço de papel, mas isso não vai ouvi-lo.

(Veja também A Tirania da Estruturação )

pjc50
fonte
19
Isso é incrivelmente importante para as equipes que lidam com código legado. Especialmente ao passar do código seguindo um conjunto de padrões (ou não seguindo nenhum padrão) para outro. Sem uma diretriz para se referir, é impossível dizer qual estilo de código seguir quando houver vários estilos já presentes na base de código. Penso que o conselho para não anotar os padrões se destina a equipes muito pequenas que trabalham em projetos greenfield sem rotatividade de riscos - um caso muito raro, na minha experiência.
24516 thomij
4
É muito mais importante concordar com um padrão do que o conteúdo real do padrão. Você pode se acostumar com praticamente qualquer estilo se trabalhar com ele por tempo suficiente.
Mark Ransom
3
Discutir sobre trivialidades é um sinal de incompetência, IMHO. A resolução da disputa concreta não resolverá o problema subjacente.
Jørgen Fogh
11
Sim, a resolução de disputas e manter o histórico de alterações não poluído são enormes, especialmente quando você tem uma mistura de desenvolvedores de TOC e não tão TOC em sua equipe. No entanto, descobri que os padrões escritos são árbitros muito menos eficazes do que ferramentas automatizadas como o StyleCop, que estabelecem a lei sem torná-la pessoal ou desperdiçar o tempo dos gerentes.
Eric Hirst
12
"Discutir sobre trivialidades é um sinal de incompetência" - Eu gostaria que isso fosse verdade em engenharia de software ... Receio que alguns desenvolvedores muito, muito competentes (pelo menos tecnicamente) sejam exatamente as pessoas que mais gostam de discutir sobre trivialidades. Inferno, é o esporte nacional deles. "Infinitos são os argumentos dos magos" -Ursula Le Guin
Spike0xff
21

Porque comentários são mentiras .

O padrão de codificação é um grande comentário sobre o que o código deve ser. O código em si é a fonte última da verdade. A verdade, neste caso, não é o comportamento do código, é o estilo em que ele é expresso. Se seus padrões ainda não estão refletidos no seu código, você tem muito trabalho pela frente.

O tio Bob vê um comentário como falha pessoal do programador, porque prova que ele não conseguiu expressar o objetivo do fragmento de código com a própria linguagem de programação. Da mesma forma, um documento de padrões é uma falha ao expressar um estilo coerente na base de código.

Os novos programadores devem passar um tempo olhando o código, sem passar dias lendo um documento de normas com vários capítulos (eu tive que fazer isso, suspiro).

Um documento de normas não é uma má idéia, mas eu estive em lojas de programação em que a manutenção dos documentos de normas era o trabalho de alguém em período integral. Por favor, se você precisar manter um documento de normas, mantenha-o em uma página. Mas se você já possui código, ninguém deveria conseguir montar o mesmo documento em menos de um dia?

Ter padrões de código é importante. Ter um documento que dita o que são não é.

candied_orange
fonte
22
Na verdade, experimentei a base de código de várias décadas com a política "sem comentários"; embora encoraje nomes de métodos descritivos muito longos, é absolutamente terrível capturar intenções, razões para não fazer as coisas e só nos damos bem com um dos autores originais ainda conosco.
Pjc50
7
+1 "Ter padrões de código é importante. Ter um documento que dita o que são não é." Bem e de forma sucinta.
David
4
@ pjc50 Eu nunca ouvi o tio Bob encorajar uma política de não comentar. Ele não ensina que você nunca deve comentar. Ele ensina que você deve se sentir mal quando achar que precisa fazê-lo para ser entendido. Não legível não comentado <comentado ilegível <código legível que não precisa de comentários. Observe que os comentários mencionados são completamente dissociados de COMO o código funciona. Os documentos de padrões podem se transformar em uma lista de verificação de morte cerebral marcada em uma revisão de código. O importante não é que você receba todos os seus ticks. É que as pessoas na mesa entendem seu código.
Candied_orange 24/05
3
"Novos programadores devem gastar tempo olhando o código, não gastando dias lendo um documento de normas com vários capítulos". Não faço ideia dos guias de codificação que você segue, mas o guia de estilo C ++ do Google pode ser facilmente lido em menos de uma hora e é muito mais fácil descobrir do que ter que fazer engenharia reversa do estilo preferido com base no código existente (o que me parece horrível). O mesmo vale para todos os outros guias de estilo que já li.
Voo 24/05
5
@CandiedOrange: Freqüentemente, os comentários mais úteis são os que descrevem o motivo pelo qual certas coisas não foram feitas [uma vez que, na ausência de tais comentários, futuros programadores podem perder tempo tentando implementar e depois retrair "melhorias" aparentemente óbvias que por ser inviável]. A menos que alguém enlouqueça com nomes de variáveis, não há como o código mais legível de ler capturar essas informações.
Supercat 24/05
16

Por que o tio Bob sugere que os padrões de codificação não devam ser anotados se você pode evitá-lo?

Se você está perguntando as razões por trás da opinião dele, poderá ter uma resposta apenas se ele postar uma resposta aqui ( nossa opinião é irrelevante), no entanto ...

Por que não devo escrever um padrão de codificação?

Se você está perguntando se ele está certo : deixe-me ser o único impopular (até agora) a dizer que você não tem motivos para evitá-lo.

ESCREVA PARA BAIXO . No entanto, vou tentar explicar minhas razões ...

David sugeriu em um comentário que o ponto principal da resposta de Stephen não é por que você não deve escrever documentos, mas de que forma eles são. Se as diretrizes são formalizadas em ferramentas (não apenas na revisão manual de códigos), posso concordar (quando a lei não exige outra coisa). Observe que, infelizmente, as ferramentas não podem verificar tudo (a teoria da computação não é nossa amiga) frequentemente porque estão limitadas a uma unidade ou pacote de tradução específico ou seja qual for o seu idioma favorito chamar de limite .

No entanto, as palavras do tio Bob não me fazem pensar que ele está falando sobre isso.

Posso discordar desse especialista sênior? Sim, em quase todos os pontos do post citado (veja também a segunda parte desta resposta para obter detalhes). Vamos tentar entender o porquê (supondo que você já saiba que as diretrizes de codificação não são apenas sobre pequenos problemas de formatação ).

  • Em algumas circunstâncias, os padrões de codificação por escrito são exigidos por lei.
  • Eu leio a documentação e tenho certeza de que não estou sozinha. Os membros da equipe podem mudar com o tempo, o conhecimento não pode estar em uma base de código de 5 a 10 anos ou na mente dos membros da equipe. As organizações devem demitir pessoas que não seguem as diretrizes internas.
  • Os padrões de codificação, depois de aprovados , não mudam com frequência e se você deseja saber sobre isso. Se os padrões foram alterados, sua documentação (em código) está desatualizada porque todo o seu código não segue o novo padrão. A reformatação / refatoração pode ser lenta, mas você sempre tem uma orientação autorizada por escrito a seguir.
  • É melhor ler um documento de 5 páginas do que inspecionar 10 / 20K LOC para extrapolar uma regra (que você pode entender errado, BTW), sem dúvida.
  • É irônico que alguém que escreveu muitos livros sobre princípios de design e estilo de codificação esteja sugerindo que você não escreva suas próprias diretrizes, então não é melhor se ele nos der um exemplo de código? Não, porque as diretrizes escritas não apenas lhe dizem o que fazer, mas também duas outras coisas que o código não tem: o que não fazer e razões para fazê-lo ou não.

A "programação auto-organizada gratuita" é boa para um ninja de 16 anos, mas as organizações têm outros requisitos :

  • A qualidade do código deve ser concedida (e definida) no nível da empresa - não é algo que uma única equipe possa decidir. Talvez eles nem tenham as habilidades necessárias para decidir o que é melhor (quantos desenvolvedores, por exemplo, possuem todas as habilidades necessárias para revisar o MISRA ou até mesmo entender apenas cada regra?)
  • Os membros podem ser movidos por equipes diferentes: se todos seguirem os mesmos padrões de codificação, a integração será suave e menos propensa a erros.
  • Se uma equipe é auto-organizada, os padrões evoluirão com o tempo quando os membros da equipe mudarem - você terá uma enorme base de código que não segue os padrões atualmente aceitos .

Se você está pensando nas pessoas antes do processo , só posso sugerir a leitura sobre o TPS: os seres humanos são uma parte central do Lean, mas os procedimentos são altamente formalizados.

É claro que uma organização pequena com apenas uma equipe pode deixar que a equipe decida os padrões a serem adotados, mas deve ser anotada. Aqui, no Programmers.SE, você pode ler as postagens de Eric Lippert: Suponho que todos concordamos que ele é um desenvolvedor experiente; quando trabalhou na Microsoft, ele teve que seguir suas diretrizes escritas (mesmo que algumas regras possam estar erradas , não aplicáveis ou inúteis). para ele.) E Jon Skeet? As diretrizes do Google são bastante rigorosas (e muitas pessoas não concordam com elas), mas ele deve seguir essas diretrizes. É desrespeitoso para eles? Não, eles provavelmente trabalharam para definir e melhorar essas diretrizes, uma empresa não é feita por um membro (ou uma equipe) e cada equipe não é uma ilha .

Exemplos

  • Você decidiu não usar herança múltipla e classes aninhadas em C ++ porque os membros reais da equipe não a entendem bem . Mais tarde, alguém que queira usar herança múltipla deve procurar o LOC inteiro 1M para ver se ele já foi usado. É ruim porque, se as decisões de design não estão documentadas, você precisa estudar toda a base de código para entendê-las. E mesmo assim, se não foi usado, é porque é contra o padrão de codificação ou é permitido, mas simplesmente não havia situações anteriores em que a herança múltipla se encaixava bem?
  • No C #, você tinha métodos sobrecarregados para fornecer parâmetros padrão, porque sua base de código foi iniciada quando parâmetros opcionais não estavam disponíveis no C #. Em seguida, você alterou e começou a usá-los (refatorando o código antigo para usá-lo toda vez que você precisava modificar essas funções). Mais tarde, você decidiu que os parâmetros opcionais são ruins e começa a evitar usá-los. Qual é a regra que seu código diz? É ruim porque o padrão evolui, mas a base de código é mais lenta e, se for sua documentação, você está com problemas.
  • Jon passou da equipe A para a equipe B. Jon precisa aprender um novo padrão; enquanto estiver aprendendo, ele provavelmente introduzirá erros mais sutis (ou, se tiver sorte, levará muito tempo para entender o código existente e tornar a revisão do código mais longa).
  • A equipe A passa para uma base de código pertencente à equipe B. Ele possui padrões de codificação completamente diferentes. Reescrever? Adaptar? Misturar? Todos eles são igualmente ruins.

Tio Bob

Deixe-os evoluir durante as primeiras iterações.

É verdade, até que você não tenha um padrão e sua organização tenha atribuído a você a tarefa de criar um.

Deixe que eles sejam específicos da equipe, e não da empresa.

Não, por todos os motivos explicados acima. Mesmo que você pense em formalizar apenas a formatação de código (a coisa menos útil que você pode querer formalizar) ainda tenho memória de guerras intermináveis ​​(e inúteis) sobre formatação. Não quero vivê-los repetidamente, defini-lo de uma vez por todas.

Não as anote se puder evitá-la. Em vez disso, deixe o código ser o modo como os padrões são capturados.

Não, por todos os motivos explicados acima (é claro, a menos que você refatore todo o seu código de uma só vez quando as diretrizes mudarem). Deseja deixar seu código como está? Como você inspeciona a base de código para entender as diretrizes atuais ? Procurando por idade do arquivo e adaptando seu estilo de codificação à idade do arquivo de origem?

Não legislar um bom design. (por exemplo, não diga às pessoas para não usarem o goto)

É verdade que as diretrizes devem ser curtas ou ninguém as lerá. Não repita o óbvio.

Certifique-se de que todos saibam que o padrão é sobre comunicação e nada mais.

Além disso, um bom padrão diz respeito à qualidade, a menos que você queira ter apenas um padrão sobre pequenos detalhes.

Após as primeiras iterações, reúna a equipe para decidir.

Veja o primeiro ponto e não esqueça que um padrão de codificação geralmente é um processo que levou muitos anos para ser desenvolvido e refinado: poucas iterações, talvez com desenvolvedores juniores? Realmente? Deseja confiar na memória de um membro sênior (se houver)?

Três notas:

  • Na minha opinião, as desvantagens são mais graves em algumas linguagens do que em outras, por exemplo, em C ++, um padrão no nível da empresa é ainda mais necessário do que em Java.
  • Esse raciocínio pode não se aplicar inteiramente (e os motivos do tio Bob podem ser menos extremos ) se você estiver trabalhando em uma empresa muito pequena, onde você tem apenas uma equipe pequena.
  • Você é contratado (como equipe) e trabalhará sozinho com um novo projeto, depois o esquecerá e seguirá em frente. Nesse caso, você pode não se importar (mas seu empregador deve ...)
Adriano Repetti
fonte
5
Eu diminuí a votação porque acho que a resposta está fora de tópico para a pergunta, e é por isso que você (e especificamente o tio Bob) não escreveu um padrão de codificação , e não por que deveria. Eu acho que todo mundo entende os pontos positivos de ter um padrão escrito, mas as desvantagens são mais difíceis de determinar e quando um sênior da indústria ressecado sai com uma posição que se opõe à prática usual na indústria, examinando por que certamente é algo que vale a pena fazer.
Jules
5
@gnat obrigado, eu não preciso de votos para posts fora do tópico, não é "Por que o Sr. X fez Y?" off-topic neste caso? Não sabemos os motivos dele e ele não os explicou. Não deveria ser encerrada a pergunta como fora de tópico? Como você responderia a esta pergunta? Inventar razões aleatórias ou dizer que a premissa está errada?
Adriano Repetti
11
@AdrianoRepetti - O tio Bob fez muitas explicações ao longo dos anos, por isso é razoável considerar que alguém pode ter alguma ideia de seu modo de pensar, mas você está correto se a interpretação direta do tio Bob for necessária.
JeffO 24/05
3
@jeff sim, se a pergunta é sobre "por que ele pensa assim", então a resposta é apenas um palpite. Se a pergunta é "está certo?" então minha resposta pessoal é absolutamente nenhuma.
Adriano Repetti
11
"quando ele trabalhou para a Microsoft, teve que seguir as diretrizes escritas" - você pode apostar que sim. E é claro que fez uso de FXCop e StyleCop para evitar alguns padrões ruins de cada vez como se checar.
Eric Lippert
12
  1. Para ser útil, um padrão de codificação não deve falar sobre questões de substância; apenas questões de estilo. Ele deve especificar apenas as coisas arbitrárias e ambíguas. por exemplo, posicionamento da chave, profundidade do recuo, espaços versus guias, convenções de nomes, etc.
  2. Questões de estilo são locais, não globais. Cada equipe deve adotar seu próprio estilo peculiar, compatível com sua tarefa e sua personalidade. Isso mantém os padrões simples e leves. Os padrões corporativos ficam sobrecarregados com todas as considerações, configurações e exceções possíveis.
  3. Dentro de uma equipe, o único motivo para escrever um documento separado de estilo de codificação é se o código produzido pela equipe não atender ao padrão. Nesse caso, você não tem padrão. Para ser eficaz, o padrão deve ser expresso pelo próprio código. E se for assim, não há necessidade de um documento separado.
  4. Nos sistemas legados, as equipes e os estilos mudam com o tempo. Não há nada de errado nisso. O código antigo terá um estilo mais antigo. O código mais recente terá um estilo mais novo. A equipe deve estar ciente dos estilos e idades. Sempre que um novo código é escrito, ele deve estar no novo estilo, independentemente do local em que está localizado.
Robert Martin
fonte
Tenho poucas perplexidades: 1) para ser útil, um padrão de codificação não deve falar apenas sobre formatação (questão de guerras sagradas, mas fácil de entender o código de leitura), mas construções a evitar, padrões de codificação (para evitar erros comuns, não é fácil entender a linguagem). recursos) e problemas de segurança. Estas são diretrizes de codificação (mais úteis que problemas de formatação). 2) Dada a premissa do ponto 1, não se trata de personalidade (mas pode ser sobre tarefas ), você pode ter um padrão corporativo leve, é seu próprio dever torná-lo leve.
Adriano Repetti
3) O código pode lhe dizer o que fazer, mas não pode transmitir o que você não deve fazer (a menos que você queira estudar toda a base de código e mesmo nesse caso ... simplesmente não teve que usar a construção X ou é um não-não?) Outra coisa importante é o raciocínio: por que não? e porque sim? As coisas podem mudar com o tempo, mas como você sabe se as premissas iniciais ainda são válidas? 4) e quando você é um novo membro da equipe e escreve um novo código ... você estuda a base de código com a mesma idade para manter esse estilo de codificação? O dia depois de mover para outro componente mais recente e você estudar base de código novamente (filtragem por data de criação?)
Adriano Repetti
BTW, se, em vez disso, você sugerir que não escreva apenas estilos de formatação de código, eu posso concordar (bem, na verdade não, mas com razões não tão fortes além das memórias de discussões intermináveis ​​e inúteis que inevitavelmente surgirão a cada vez - e que uma diretriz corporativa evitará uma vez por todas), no entanto, você deve deixar claro ou as pessoas interpretarão suas palavras muito literalmente (veja a maioria das respostas + comentários aqui). Também nesse ponto sobre "goto" é um pouco enganosa neste sentido (IMO)
Adriano Repetti
4

Por que não devo escrever um padrão de codificação?

Há muitas razões para isto. Aqui estão algumas considerações:

  1. Quanto tempo as pessoas gastam "aprendendo" os padrões de código apenas para ter muito tempo para toda a equipe revisar, discutir, documentar, revisar ... etc. os padrões de código. É como discutir constantemente o seu "Manual do funcionário" - com que frequência isso faz parte da agenda de uma reunião de equipe?

  2. Quando um projeto é reembolsado / arquivado / etc. então, as poucas pessoas que permanecem geralmente não podem continuar aderindo (ou talvez nem tenham lido) os padrões. A próxima coisa que você sabe, todo esse esforço para "manter o código limpo" foi praticamente desperdiçado.

  3. Se o projeto for interrompido ou surgir um novo lead, é muito provável que essa pessoa ignore totalmente as regras anteriores e deseje fazê-lo de uma nova maneira. Novamente, o que foi ganho pela codificação de padrões?

Você deve ler # 6:

Após as primeiras iterações, reúna a equipe para decidir.

Em outras palavras, quando é hora de iniciar um projeto, basta seguir o fluxo por um tempo. Depois, discuta as regras gerais dos padrões de codificação que a equipe atual está usando - e basicamente siga-as. Dessa forma, você maximiza o esforço necessário para melhorar o produto e minimiza o esforço necessário para escrever, revisar e documentar o "açúcar sintático" usado na obtenção de código executável.

Muito poucas equipes obtêm enormes benefícios dos padrões de codificação. Geralmente, a "legibilidade" é muito vaga - e a maioria dos desenvolvedores não se beneficia muito com regras exatas sobre espaçamento, novas linhas, etc., mas você pode evitar desenvolvedores constantemente irritantes , tendo pelo menos algumas regras.

Jim
fonte
4

Outra resposta que não acho que tenha sido declarada com clareza suficiente é que isso também significa que as pessoas não seguem as regras cegamente. Isso significa que as pessoas precisam apresentar justificativas reais para suas decisões de design e convenções de codificação, em vez de depender apenas do fato de que elas foram escritas para justificá-las.

Finn O'leary
fonte
4

Em primeiro lugar, até onde eu sei, o tio Bob é uma pessoa Java, isso é muito importante para entender o que ele diz.

Ao trabalhar em uma equipe Java ou C #, se o código atual foi escrito por desenvolvedores experientes, é fácil para mim pegar o estilo de codificação e segui-lo. Se eu não estiver disposto a fazê-lo, talvez eu não seja a pessoa certa para o trabalho ... Se não houver revisão de código ou programação emparelhada para me buscar quando eu não seguir o estilo, a empresa terá um problema maior do que a maneira como nomeio os campos dos membros!

Java e C #, juntamente com a maioria das linguagens modernas, foram definidos para que existam poucas armadilhas "simples" para um programador se encaixar.

No entanto, quando comecei a programar, estava usando C (e depois C ++). Em C, você pode escrever código como

if (a = 3);
{
   /* spend a long time debugging this */
}

O compilador não dará um erro, e isso é difícil de detectar ao ler muito código. No entanto, se você escrever:

if (3 = a)
{
   /* looks odd, but makes sense */
}

O compilador apresenta um erro e é fácil alterar o código para 3 == a. Da mesma forma, se o padrão de codificação não permitir =ser usado dentro de uma ifcondição ou " ifdeclaração vazia ", um verificador de código poderá ser usado como parte do sistema de construção para rastrear esse erro.

Minhas visões sobre os padrões de codificação mudaram bastante quando me afastei do C / C ++: eu gostava de padrões de codificação que eram rigorosamente impostos e com muitas páginas. Agora, acho que você só precisa listar as ferramentas que estão sendo usadas e obter um acordo informal entre os membros originais da equipe em algumas convenções de nomenclatura. Não vivemos mais em um mundo de equipes de mais de 30 desenvolvedores que escrevem aplicativos em C / C ++ ...

Há uma razão pela qual nunca gostei do JScript e acho que o TypeScript é a melhor coisa que acontece no desenvolvimento da web há anos. Espero que os desenvolvedores da interface do usuário da Web ainda precisem de padrões de codificação devido aos defeitos no design de HTML / CSS / JScript etc.

Ian
fonte
4
"O compilador não dará erro" A maioria dos compiladores modernos de C e C ++ oferece suporte para relatar esse comportamento com avisos ou, se desejado, com erros completos. gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
JAB
2
"Em primeiro lugar, tanto quanto eu sei que o tio Bob é uma pessoa Java, isso é muito importante para entender o que ele diz", isso não é verdade, o tio Bob escreveu artigos fantásticos sobre C ++ e ele definitivamente trabalhou vários anos com C também.
Alessandro Teruzzi
@JAB, Felizmente, o C / C ++ deixou de ser usado para novos "aplicativos de negócios" há muito tempo (por exemplo, antes dos compiladores de modem C / C ++) e agora é usado principalmente apenas por especialistas em C / C ++, e não por pessoas que são especialistas em UI (MFC), por exemplo.
24516 Ian
11
@AlessandroTeruzzi Um teste de unidade informa que um método está falhando. Por que está falhando é uma questão diferente - mesmo se você tivesse testes de unidade para um método com esse tipo de código, seria muito difícil tentar descobrir o que está acontecendo de errado. C ++ é uma das linguagens mais exigentes para depuração.
T. Sar
2
Eu acho que há um mal-entendido aqui, você não pode pegar uma única frase do UncleBob e analisá-la isoladamente. Se você possui o software SOLID com classes pequenas, método curto e cobertura de teste de unidade à prova de balas, o padrão de codificação é redundante. Se você tem código fraco, interface enorme, grandes funções e pouca cobertura, o padrão de codificação pode lhe dar algum benefício. Porém, o UncleBob não está sugerindo não ter um, mas espalhá-lo verbalmente com colaboração e refatoração (remova o código fraco da base de origem). Faça do seu código o padrão de codificação vivo.
Alessandro Teruzzi
3

Ter a fonte como padrão de codificação de auto-documentação implica duas coisas.

  1. As pessoas devem consultar a base de código e revisá-la para se tornarem colaboradores proficientes. Isso é incrivelmente importante. Ler as diretrizes de codificação é uma perda de tempo em comparação com mergulhar na base de código.
  2. Ele reconhece que pequenas diferenças não são importantes. É importante concordar e entender os princípios básicos. A manutenção de um estilo consistente não é seguida como l'art pour l'art. Não permite nitpickers não criativos irritar e distrair outras pessoas. Trata-se de facilitar a comunicação através do código em uma equipe.
Peter A. Schneider
fonte
2

Um documento de padrões de código atualizado e bem escrito com freqüência pode ser muito útil, mas geralmente esse não é o caso. O documento de normas não reflete os padrões de codificação atuais usados ​​pela empresa, pois é muito difícil criar um bom documento e ainda mais difícil mantê-lo atualizado.

Em vez de ter um documento de padrões de codificação ruim e enganoso, é melhor não ter nenhum e deixar que o próprio código represente esses padrões. De qualquer maneira, a parte mais importante é aplicar os padrões no código, e isso requer muito mais do que apenas um documento. Motivação, processos, treinamentos, ferramentas etc são muito mais importantes.

DesignerAnalyst
fonte
2

Uma coisa muito importante que não foi declarada com clareza suficiente é que os padrões de codificação são como a linguagem: eles evoluem. Um padrão de codificação escrito fica no caminho disso, e se não o fizer, é continuamente desatualizado e inútil.

Não ter um padrão de codificação pregado não é tão ruim assim. Se você fizer análises por pares no check-in, sempre que algo que não esteja em conformidade com o padrão de codificação entrar no repositório, isso significa que 2 pessoas pensaram nisso * e decidiram que o benefício dessa variação supera a inconsistência com o restante do código.

Não ter um padrão anotado também remove a burocracia que impediria uma equipe de uma empresa de experimentar uma nova variação do padrão de codificação para um novo projeto, seja porque eles querem experimentar alguma coisa, ou talvez porque um padrão diferente tenha aplicações práticas. em algumas das ferramentas automatizadas que eles usam.

A anotação de um padrão tende a remover mais flexibilidade do que o inicialmente previsto, além de levar bastante tempo que poderia ser gasto em outras coisas. Eu não estou dizendo que você nunca deve escrever padrões de codificação, eles certamente têm seus benefícios, especialmente se as equipes que trabalham em locais diferentes trabalham na mesma base de código.

Fortemente relacionado: Evolução dos padrões de codificação, como você lida com eles?


* Se as pessoas não pensam enquanto analisam o código no check-in, seus problemas são muito maiores do que apenas os padrões de codificação.

Peter
fonte
1

Mudá-los se torna um grande obstáculo, e as pessoas aderem com segurança à letra da lei, em vez de se empenharem e fazerem a coisa certa.

Chegará o dia em que parte do padrão será inútil e tornará o código pior. Algumas pessoas aderem ao padrão, porque está escrito e seguro, e porque existem regras a serem seguidas. As pessoas que desejam escrever um bom código em vez de código compatível com o padrão ficarão frustradas e irritadas. Haverá argumentos e discordâncias, enquanto que, se o padrão não fosse escrito, haveria exploração e discussão.

Moschops
fonte
0

Eu acho que muitos posts aqui são um padrão de codificação confuso com um guia de estilo .

Garantir que os módulos desenvolvidos por equipes diferentes tenham as mesmas opções de compilador e ABI é um tipo diferente de quantos espaços são recuados.

Coisas como a maneira correta de estruturar arquivos #include e não poluir o espaço para nome global em um arquivo de cabeçalho devem ser documentadas para que possam ser usadas como uma lista de verificação durante a codificação inicial e as revisões de código.

Em particular "não use XXX porque provoca problemas de compatibilidade com YYY" não é algo que você ver por exemplo em seguir outro código, uma vez que é não existe. Portanto, deixe que o código seja o modo como os padrões são capturados pode não ser claro ou totalmente ausente para alguns tipos de padrões e, portanto, esse não pode ser um plano universal.

Algo seriamente difundido e importante, como não usar exceções ou não newem certos sistemas embarcados, não pode ser simplesmente deixado como conhecimento comum da cultura, já que "a informação é cultural (apenas)" contradiz os princípios fundamentais dos padrões de fabricação como ISO-9000, que o desenvolvedor desses sistemas embarcados está usando (por exemplo, para aplicações automotivas). Essas coisas importantes devem ser documentadas, assinadas e arquivadas de maneira formal.

Mas isso se aplica à codificação , não ao estilo .

Os inventores de C e C ++ mostram, por exemplo, o uso de nomes em minúsculas e não o CaMelCaSe. Então, por que tantos desenvolvedores não seguem o exemplo implícito da fonte? O estilo da biblioteca padrão e os materiais de ensino canônicos não devem ser o estilo implícito a seguir?

Enquanto isso, as pessoas fazem seguir o exemplo dos cabeçalhos da biblioteca padrão para coisas que não devem ser copiados, como o uso de __Uglynomes de parâmetros macro e o arquivo de inclusão não-padrão de repetição.

Portanto, ter coisas geralmente não é visto como um estilo importante ou, inversamente, ter exemplos pode não ser claro quanto ao que não deve ser seguido no código do projeto. Ambos são contra-exemplos da tese de que "estilo" (ou convenções de codificação) é melhor deixar implícito.

JDługosz
fonte