Qual a importância das diretrizes de formatação de código? [fechadas]

Os padrões de codificação são comuns em qualquer organização de desenvolvimento de software, mas qual a importância deles a seguir? Eu posso entender a necessidade de alguma consistência, mas ao lidar com coisas simples, como posição de chaves, comprimento de linha, etc., não tenho certeza de que padrões excessivamente rígidos contribuam muito para o desenvolvimento de software.

Não é mais importante que seu código seja legível, não que esteja em conformidade com um padrão predefinido? Parece que eles são mais ... orientações de qualquer maneira.

Pedir a todos que sigam 100% da mesma diretriz de formatação de código padrão é como pedir a todos que colaborem separadamente na redação de um artigo de 100 páginas com o mesmo estilo de escrita.

Espero que todos escrevam o artigo em inglês (ou mesmo idioma), mas estilos diferentes serão aparentes. Alguns escreverão bem, outros não. Alguns usam contrações, outros soletram completamente as palavras (exemplo: é verdade). Etc.

Eu acho que você tocou nos pontos mais importantes:

1. É uma diretriz
2. Legibilidade

Se você deseja que o código adote a mesma formatação, como um papel com o mesmo estilo de escrita, será necessário editar e revisar. O código precisará ser limpo, revisado, refatorado etc.

Eu nunca estive em uma loja onde fiquei completamente feliz com o estilo de codificação ou a formatação de outro desenvolvedor (no mínimo porque não é exatamente como o meu). Mas ficarei contente se puder ler / entender e se for consistente. Tudo o resto é o açúcar no açúcar sintático.

Então, para responder à sua pergunta: um pouco importante, mas certamente não é o fim do mundo, se não o fizer.

Para padrões de formatação, sigo o que todo mundo está fazendo. Se eles estão usando o PascalCase para tudo, eu uso o PascalCase. Se eles usam _camelCase, então eu uso _camelCase. Por quê? Porque limita a quantidade de reformatação que faço e o que os outros precisam fazer para que "pareçam bons". Os padrões de formatação geralmente estão lá para facilitar as coisas para todos.

No meu trabalho atual, uma das minhas primeiras tarefas foi criar um padrão de codificação para o nosso grupo de desenvolvimento.

Meu primeiro esforço teve cerca de sessenta páginas (ele incorporou grande parte das Diretrizes da Estrutura da Microsoft). Pediram-me para reduzi-lo, e meu próximo esforço foi de dez páginas, utilizando idéias de várias fontes boas. Pediram-me para reduzi-lo novamente e finalmente reduzi-o para três ou quatro páginas, eu acho.

Nunca foi adotado.

Por quê? Porque trabalho com muitas pessoas realmente inteligentes, que já seguem instintivamente um padrão de codificação sensato.

Da minha parte, sigo as diretrizes geralmente aceitas da Microsoft e emulo os estilos mais usados ​​de outras pessoas (Javascript e jQuery são formatados de maneira diferente do C #, mesmo que sejam linguagens entre chaves). Eu também quebro as regras de tempos em tempos, quando isso torna o código mais legível.

Se você usa um IDE que faz o básico disso para você (Visual Studio, por exemplo), deixe o IDE fazer suas coisas e tudo o que parece ainda ser difícil de ser modificado, desde que você ainda permita que o IDE faça suas coisas ou a próxima pessoa que formata automaticamente, vai matá-lo de qualquer maneira.

O que é mais legível para uma pessoa não será para todas as pessoas.

Se você não estiver usando esse tipo de IDE, obtenha um. Mesmo pensando sobre isso por mais de 10 minutos é um desperdício de recursos IMHO.

Eu acho que há um benefício não mencionado em ajudar a entender rapidamente o código. Quanto mais semelhante for a formatação do código em um projeto e em todos os desenvolvedores, mais fácil (e mais subconscientemente) você poderá trabalhar com o código.

Eu tive desenvolvedores juniores que vieram até mim depois de tentar lidar com erros simples mesmo por um longo período de tempo. Depois de alguns minutos para aplicar nosso formato de código com eles, eles foram capazes de ver rapidamente o bug que haviam perdido antes.

Embora a legibilidade seja definitivamente importante. Se seus padrões de formato de código forem bem pensados ​​e usados ​​corretamente, você poderá ir além de apenas ler o código e entender o código ainda mais rapidamente.

Um conjunto de diretrizes que uso ao desenvolver ou atualizar nossos formatos de codificação é o Princípios de agrupamento da Gestalt - http://en.wikipedia.org/wiki/Gestalt_psychology#Gestalt_laws_of_grouping

Como resultado direto / exemplo, nossa formatação de código exige que qualquer código de bloco (if, switch, etc.) tenha a chave aberta na próxima linha, para que ela se alinhe com a chave de fechamento:

if(true)
{
}

Com o raciocínio de que, pelo Princípio da Simetria, sua mente verá as chaves de abertura e fechamento e mais rapidamente será capaz de perceber o bloco de código naturalmente.

Não importa qual idioma ou ferramenta você use, crie alguma coisa. Configure seu IDE e faça o check-in no arquivo de configuração.

Quando alguém faz check-out do projeto, eles usam os mesmos estilos de formatação. Não importa qual é o estilo, apenas que seja consistente. Eu tenho minhas próprias preferências com relação aos espaços v. Guias, e a linha que os aparelhos encaracolados continuam. Mas mais do que minhas próprias preferências, eu apenas me importo que um determinado arquivo de código-fonte esteja de acordo. Isso o torna muito mais legível do que ser uma bagunça resultante de uma guerra de formatos.

A pior coisa que encontrei até agora é não usar padrões de codificação. E você está proibido de tornar mais legível algum bloco de código, pois ele quebra as ferramentas diff ... Porque estamos usando patches para aplicar alterações (solicitação de alteração / correção de bug -> correção / alteração -> correção -> correção aplicada por pessoa "confiável" -> commit) você pode obter um código fonte com aparência muito engraçada (do ponto de vista da legibilidade). Pelo menos não temos ninguém usando variáveis ​​de duas letras (-.

[engraçado] O mais engraçado é que todos concordam que precisamos mudar isso. Houve até algumas tentativas de reformatação (automatizadas no commit), mas porque uma única opção minúscula de formatação está faltando - tudo acabou. Vista ...

As diretrizes ajudam a melhorar a qualidade do código:

• do ponto de vista do escritor: muitas regras visam reduzir a introdução de bugs. Por exemplo, uma regra que declara que if()ou for(;;)construções devem ser seguidas por um bloco e não por uma única instrução, torna explícita a intenção do codificador inicial e ajuda os próximos codificadores a manter isso.

• do ponto de vista do leitor: o código que segue as diretrizes acordadas é revisado com mais eficiência do que o código com vários estilos. O revisor sabe melhor, com menos esforço, onde procurar possíveis erros.

Não existe um padrão universal para o que uma equipe deve ou não fazer. Algumas equipes precisam seguir diretrizes rígidas, outras não.

O ponto é que você deve trabalhar em equipe e decidir o que é melhor para sua equipe . O código deve ser fácil de ler, porque é uma ordem de grandeza de leitura mais vezes do que está escrito. Se sua equipe precisar de orientação para criar código legível, siga um padrão de codificação. Se não, não.

Tudo isso dito, acho que a maioria das equipes se beneficiaria de concordar com uma maneira padrão de nomear variáveis, funções e classes, chaves de posição e assim por diante. Se a equipe não pode concordar com algo tão simples como isso, como eles podem se unir e tomar decisões realmente importantes? Além disso, sua equipe não será composta das mesmas pessoas para sempre - as pessoas saem, novas pessoas são contratadas. Quanto mais fácil é para as novas pessoas entenderem a base de código, mais rapidamente elas podem contribuir para a equipe sem diminuir a qualidade do código.