É uma boa idéia impor o mesmo formato de código para todos os desenvolvedores?

Estamos pensando em impor um único formato de código padrão em nosso projeto (formato automático com ações de salvamento no Eclipse). O motivo é que atualmente há uma grande diferença nos formatos de código usados ​​por vários (> 10) desenvolvedores, o que dificulta que um desenvolvedor trabalhe no código de outro desenvolvedor. O mesmo arquivo Java às vezes usa 3 formatos diferentes.

Então, acredito que a vantagem é clara (legibilidade => produtividade), mas seria uma boa ideia impor isso? E se não, por que?

ATUALIZAÇÃO
Todos nós usamos o Eclipse e todos estão cientes do plano. Já existe um formato de código usado pela maioria, mas não é imposto, pois alguns preferem manter seu próprio formato de código. Por causa das razões acima, alguns preferem aplicá-lo.

Atualmente, trabalho em um local em que um formato de código padrão é imposto e o código é formatado automaticamente ao salvar o arquivo, exatamente como você está prestes a fazer. Como um novo membro da empresa, descobri que as regras comuns de formatação me davam uma sensação calorosa e confusa de que "esses caras sabem o que estão fazendo", então eu não poderia estar mais feliz. ;) Como uma observação lateral relacionada, com as regras de formatação comuns, também aplicamos certas configurações de aviso do compilador bastante estritas no Eclipse, com a maioria delas definida como Erro, muitas definidas como Aviso e quase nenhuma definida como Ignorar.

Eu diria que há duas razões principais para impor um formato de código único em um projeto. O primeiro diz respeito ao controle de versão: com todo mundo formatando o código de forma idêntica, todas as alterações nos arquivos são garantidas. Chega de adicionar ou remover um espaço aqui ou ali, e muito menos reformatar um arquivo inteiro como um "efeito colateral" de alterar apenas uma ou duas linhas.

A segunda razão é que isso tira os egos dos programadores da equação. Com todo mundo formatando seu código da mesma maneira, você não pode mais dizer com tanta facilidade quem escreveu o que. O código se torna uma propriedade mais anônima e comum, portanto, ninguém precisa se sentir desconfortável com a alteração do código de "outra pessoa".

Essas são as principais razões, existem outras também. Acho reconfortante não ter que me preocupar em pensar na formatação do código, pois o Eclipse fará isso por mim automaticamente quando eu salvar. É livre de preocupações, como escrever documentos com o LaTeX: é formatado posteriormente e você não precisa se preocupar com isso enquanto escreve. Eu também trabalhei em projetos em que todos tinham seus próprios estilos. Em seguida, você deve pensar em questões estúpidas e sem sentido, como se não há problema em modificar o código de outra pessoa no seu próprio estilo, ou se você deve imitar o estilo deles.

O único argumento contra as configurações comuns de formatação de código que posso pensar para o seu caso é que aparentemente ele é um projeto em andamento, portanto causará muitas alterações desnecessárias em todos os arquivos, alterando o histórico real dos arquivos. O melhor cenário é se você pode começar a aplicar as configurações desde o início de um projeto.

Todo desenvolvedor de software profissional prefere adotar um padrão (bom) em vez de entrar em guerra evangélica por estilo, pelas mesmas razões que você descreveu.

Muitos desenvolvedores de software empreendem guerras evangélicas ......

Dependendo da sua posição dentro da equipe e da dinâmica da equipe, você pode decidir que vencer a guerra não é possível. Nesse caso, talvez seja melhor não iniciar ...

Sim, é bom ter um estilo de formato de código para todos os desenvolvedores.

Projete os formatos de estilo de código e importe-os para todos os desenvolvedores.

Isso ajudará quando formos mergingcodificar para o sistema 'Controle de versão'.

O que você está tentando obter, o quanto você vai reter anal ao aplicá-lo (e no nível de detalhe que suas "regras" serão definidas), você tentará aplicá-lo no código escrito em diferentes idiomas, você tentará aplicá-lo retroativamente no código existente?

1. uma aparência e um código comuns ao código podem realmente ajudar a tornar o código mais legível, mas também podem piorar as coisas se for o aspecto e a aparência incorretos. A notação _hUngarian_lpfstr é um excelente exemplo :)
2. Eu já vi "padrões de código" forçando o número de espaços em branco entre os blocos de comentários, a ordem alfabética dos nomes dos métodos e outras bobagens. Não faça isso.
3. Idiomas diferentes têm padrões diferentes com os quais as pessoas estão acostumadas a usar. Alguns até exigem esses padrões (pense que Python, Cobol, Visual Studio impõe automaticamente convenções de suporte de estilo C ++, enquanto Java usa o estilo C por convenção, etc. etc.).
4. nunca altere o código existente para alterá-lo, você está apenas introduzindo novos problemas dessa maneira. E isso significa seções de código e arquivos de origem inteiros. Portanto, não reformate o código existente quando alguém alterar uma única linha em um arquivo de 1000 linhas.
5. programadores experientes podem ser muito mais produtivos se não precisarem pensar na metade do tempo se o que estão escrevendo "parecerá correto" para o sistema de aprovação automática ou para o revisor. Eles também terão o hábito de escrever código limpo simplesmente porque é isso que funciona, mesmo que haja pequenas diferenças entre seus estilos naturais.

Portanto, embora existam boas razões para impor um estilo e padrão específico, há boas razões para não fazê-lo (também) estritamente.

Sim, consistência é uma boa ideia, por razões que outras pessoas mencionaram .

Eu só queria adicionar alguns pontos que não foram usados ​​em outros lugares:

• A Oracle publicou um conjunto de convenções para Java, que são o padrão de fato.
  • O uso dessas informações ajudará a evitar argumentos sobre qual estilo seguir.
  • Muitas bibliotecas públicas e projetos de código aberto tendem a usar essas convenções; portanto, quando você precisa examiná-las, a formatação deve ser familiar.
  • O formatador Eclipse possui regras integradas para corresponder a essas convenções, o que também deve ajudar.
• Você pode considerar criar um gancho na sua configuração de controle de origem, para que o código seja formatado automaticamente antes de entrar na ramificação principal.
  • Você pode evitar batalhas com programadores particularmente teimosos que se recusam a seguir o padrão. Eles podem até usar sua própria formatação enquanto trabalham, o que será padronizado mais tarde!
  • Se você acabar usando configurações de formatação personalizadas (por exemplo, muitas pessoas ignoram a convenção "máx. 80 caracteres por linha"), é necessário fazer alterações em um único local.

Eu estava em uma equipe que usou o plugin Checkstyle . Em vez de usar os recursos prontos para uso, formamos um pequeno comitê de desenvolvedores interessados. Debatemos o que parecia estar faltando, o que parecia excessivo e resolvemos tudo. Todos nós aprendemos algo no processo e fortalecemos esses músculos desenvolvedores.

(Exemplos de nossas decisões: 72 caracteres de largura é muito pequeno, mas 120 foi melhor; é melhor usar _ALLCAPS para finais estáticos; aplicar uma saída única de uma função é uma boa idéia.)

Quando tivemos revisões de código, uma das primeiras perguntas foi: "Você o executou no Checkstyle?" O cumprimento dos padrões de codificação foi amplamente automatizado e desviou a atenção do examinador exigente. Foi maravilhosamente fácil fazer com que o Checkstyle realce uma assinatura de método, clique com o botão direito do mouse e altere uma variável para final. Também poderia consertar os recuos e chaves, para que o código de todos tivesse uma aparência semelhante. Está faltando um Javadoc para uma função pública? O estilo de verificação sinalizará a função.

(Remover o cheiro do código é mais importante que a formatação consistente. Esse é um benefício das ferramentas automatizadas.)

Eu colocaria ferramentas automatizadas como o Checkstyle menos como impondo o mesmo formato e mais para incentivar uma aparência semelhante. E quando você está pastoreando gatos, uma ferramenta automatizada pode ajudar a aprimorar habilidades e reduzir o cheiro do código sem ferir egos frágeis.

Se você seguir o mesmo IDE e incorporar algumas ferramentas de formatação, é uma boa ideia, porque você não está exigindo muito esforço. Mantenha as regras simples, com foco na legibilidade e não na retenção anal . Esse deve ser o bastão de medição.

Embora uma bola de lama consistentemente formatada seja melhor do que apenas uma bola de lama, seria melhor gastar seu tempo limpando-a em vez de ficar muito exigente sobre onde os colchetes vão. Não entre no gerente de cabeça de alfinete que sente que está fazendo seu trabalho contando espaços de recuo durante uma revisão de código, além de garantir que as novas folhas de rosto estejam nos Relatórios TPS .

As preferências pessoais são exatamente isso e raramente melhoram a produção: https://stackoverflow.com/questions/249432/whats-the-reasoning-behind-the-different-brace-forms

Se isso acontecer, supere-o e faça algo.

Eu recomendo fortemente que os humanos apliquem a formatação do código e que pequenas infrações sejam graciosamente ignoradas ou corrigidas. Razões para isso são, brevemente,

1. A máquina erra no pior momento possível e, geralmente, quando você está usando um novo recurso de idioma. Como ele irá lidar com fechamentos em Java, etc? Jalopy tem problemas com enumerações com funções-membro.
2. Eu acho que é um fardo muito razoável colocar o programador para produzir um código para a empresa que se parece com o código da empresa. Eu achei útil mencionar que é assim que o código é formatado "aqui", não como todo o código deve ser formatado em qualquer lugar. A empresa anterior pode ter escolhido um caminho diferente, e tudo bem. Não muito diferente da linguagem vernacular, existem expressões específicas à sua cultura de código que você deseja destacar.
3. A aplicação da sintaxe do código é melhor realizada com revisões de código:
   1. Se a formatação for importante, ela atrai sua organização a fazer revisões de código. Isso é de grande benefício.
   2. Se uma regra de formatação for violada, um ser humano poderá examiná-la e julgar melhor do que uma máquina se a intenção for transmitida de maneira mais limpa. Isso é muito raro, mas acontece ocasionalmente.

Em relação à "legibilidade => produtividade", a estrutura de código (como classes e funções de responsabilidade única) comprará muito mais rapidamente do que a formatação do código. A formatação de código pode ser uma ajuda, mas mentes diferentes analisam as declarações de maneira diferente - nem todos serão "mais produtivos". Eu gostaria de dobrar a estrutura do código sobre a formatação, porque isso é algo que também o levará a fazer revisões de código e levará a equipe a pensar sobre como o programa funciona, não sobre a aparência de um único loop.

Não sou muito fã de Design Orientado a Domínio, mas é um modelo recente que tem uma idéia MUITO bem definida de como o código deve ser estruturado e as convenções de formatação de código fluem naturalmente a partir de um programa estruturado de Design Orientado a Domínio. Mais uma vez ... Eu não gosto de DDD, mas é um ótimo exemplo, porque é muito bem definido.

Suponho que o tema desta resposta seja: faça revisões de código e deixe a formatação fluir a partir da cultura e fora do processo de revisão.

Geralmente, supondo que você contrate desenvolvedores razoáveis, é uma má idéia impor um formato de código universal. No entanto, é uma boa idéia adotar diretrizes de código .

Eu nunca vi um conjunto de regras de formatação de código que otimiza a legibilidade em todos os casos. Da mesma forma, não existem regras gramaticais 100% aplicáveis ​​em inglês: nossos cérebros simplesmente não são conectados dessa maneira. Portanto, use as diretrizes, mas dê aos desenvolvedores a liberdade de substituí-las conforme entenderem.

Dito isto, uma regra mais difícil de "seguir a convenção de código que já existe no arquivo / projeto" é boa.

Mas lembre-se de que a formatação contribui muito menos para a legibilidade do que simplesmente a organização lógica do código. Eu já vi muitos códigos espaguetes ilegíveis com formatação perfeita!

Eu não acho que haja uma resposta simples para isso. Não é uma pergunta de sim ou não. Embora eu acredite que o estilo e as convenções de nomenclatura sejam importantes até certo ponto, também é muito fácil perder muito tempo pensando sobre isso. É melhor responder pelo exemplo.

Em um projeto em particular, eu não participei de convenções. Todo desenvolvedor fez as coisas à sua maneira. Devido à relativa inexperiência dessa equipe, ir de uma aula para a outra foi realmente chocante. O estilo era menos problemático do que o problema das convenções de nomenclatura. Um desenvolvedor referenciaria elementos da interface do usuário com notação húngara terrível (uma prática boba na era dos IDE modernos), um nomeava membros privados de uma maneira e outro os nomeava de maneira diferente. Você nunca sabia o que estava olhando.

No extremo oposto, uma equipe usou o StyleCop (este era um projeto .Net) como parte de seu processo de criação. O pior é que eles também usaram a maioria das regras padrão. Então, você faria algo totalmente normal em termos de espaçamento entre linhas ou posicionamento de colchetes, e a construção vomitaria por causa disso. Foi desperdiçado muito tempo adicionando espaços e linhas às coisas, e todos, incluindo os caras que insistiram em usar o StyleCop, acabaram fazendo isso quase todos os commit. Foi um enorme desperdício de tempo e dinheiro.

Então, o que estou dizendo aqui é que ser inflexível não é a resposta, mas estar no Oeste Selvagem também não é. A resposta real é encontrar o lugar que faz mais sentido, o que, na minha opinião, é não ter ferramentas automatizadas verificando coisas, mas também não jogando as convenções ao vento.

Meu principal argumento contra o estilo comum de codificação é que um programador experiente é usado para ler seu próprio estilo. Você pode treinar a mão para escrever um estilo específico, mas é quase impossível treinar os olhos para entender um estilo que você odeia. Um programador grava um pedaço de código uma vez e depois o lê repetidamente durante o desenvolvimento e a depuração. Se toda vez que ele lê seu próprio código, ele se esforça para entendê-lo, uma vez que foi forçado a escrevê-lo em um estilo MAU, ele será muito infeliz e menos produtivo. Isso é da minha experiência.

Não estou muito familiarizado com o Eclipse, mas o formato automático para salvar parece uma ideia horrível. Um desenvolvedor deve ter controle completo sobre seu código, independentemente de o estilo de codificação ser imposto ou não. A operação 'save' não deve alterar um único caractere sem o consentimento explícito do usuário.

Se sua empresa vender código fonte, o estilo de codificação será mais importante, mas se você vender código compilado, será muito menos relevante.

Esperar que o estilo de codificação torne o codificador original menos distinguível e impeça as guerras do ego é besteira no melhor dos casos e estúpido no pior dos casos. Grandes programadores sempre produzem código elegante, independentemente do estilo.

Também sou bastante favorável a dar a todos os desenvolvedores a propriedade de unidades de código específicas e a não permitir que todos toquem cada parte do código livremente. Desenvolver unidades inteiras no código e ser responsável por elas permite que o desenvolvedor se orgulhe de seu trabalho e o impeça de desenvolver códigos ruins, sabendo que os bugs retornarão para caçá-lo.

Por fim, qualquer pessoa com estilo de codificação profissional sempre assume que seu próprio estilo de codificação será selecionado e todos os outros seguirão. Imagine que o estilo de codificação que você menos gosta de todos os seus co-desenvolvedores seja selecionado como padrão. Você ainda é a favor da imposição de estilo de codificação?

Um formato para governar todos eles ... é realmente ideal?

É como dirigir o carro de outra pessoa ...

Claro que você pode entrar e dirigir qualquer carro, mas estará mais seguro, mais confortável e menos propenso a bater se dedicar algum tempo para ajustar o assento, o volante e os espelhos de acordo com SUA preferência.

Com o código, a formatação afeta seu conforto na leitura e compreensão do código. Se estiver muito longe do que você está acostumado, será necessário mais esforço mental. É necessário infligir isso aos desenvolvedores?

+1 a todos os benefícios mencionados até agora, mas ...

A imposição automática vem com custos que precisam ser considerados:

-1 ao fato de que os formatadores de código não entendem a estética da formatação de código. Quantas vezes você teve um formatador de código destruído um bloco de comentários que estava bem alinhado em forma de tabela? Quantas vezes você propositadamente alinhou uma expressão complexa de uma certa maneira para aumentar a legibilidade, apenas para que a formatação automática a transformasse em algo que "segue as regras", mas é muito menos legível?

Às vezes, existem soluções alternativas para essas coisas, mas os desenvolvedores têm coisas mais importantes em que pensar do que como impedir que o formatador automático manipule o código.

Possui regras de formatação, mas permite liberdade para aplicar o bom senso.

Bons desenvolvedores são pessoas criativas, dê a eles alguma licença artística. "Mantenha as coisas simples" deve ser o mantra dos programadores. Eu tenho duas regras:

Regra 1: forneça variáveis ​​/ cursores / objetos / procedimentos / o que for NOME SENSÍVEL. Nomes inequívocos que trazem significado e entendimento ao seu código.

Regra 2: use recuo para mostrar a estrutura do seu código.

É isso aí.

Para mim, a principal vantagem de um formato comum aplicado automaticamente é que ele ajuda no rastreamento de alterações e nas revisões de código. O git (e a maioria das outras ferramentas de controle de origem) pode mostrar diferenças das versões anteriores dos arquivos. Ao impor um estilo comum, minimiza as diferenças entre as preferências do programador.

Os guias de estilo também permitem uma análise programática mais fácil do código para vários fins analíticos.

O Google publicou um artigo sobre o assunto "Pesquisando por construir dívidas: experiências de gerenciamento de dívidas técnicas no Google" .

São idiomas, não códigos. Nós, humanos, temos mais de 6000 idiomas, por isso os traduzimos. Portanto, se você deseja que seus "códigos" se comuniquem, precisará fazer seus ajustes. Você vê que os usuários precisam alterar nossos formatos de dados para não perder nossos dados.

Eu diria que não é. Uma estrutura / formato de código comum entre uma equipe é definitivamente uma coisa boa, mas a imposição automática não é. Isso deve ser feito por seres humanos, não pelo computador.

Meus maiores problemas com o conceito são

1. Se estou escrevendo um código em um formato e ele é reformatado automaticamente, que incentivo existe para realmente aprender esse formato?
2. Seguindo esse ponto anterior, se você não aprender o formato, todo o ponto de formatação automática (para tornar o código mais fácil de ler e modificar) será completamente perdido. Você ainda precisa dedicar algum tempo para descobrir a formatação enquanto lê o código, porque ainda não aprendeu esse formato.
3. Eu acho que seria uma experiência chocante como desenvolvedor escrever uma aula um dia, fechá-la e retornar no dia seguinte para ver que é completamente diferente. Isso significa que, além de outras pessoas precisarem aprender seu código, você precisa aprender seu código.
4. Também poderia incentivar a codificação lenta. Em vez de pressionar o desenvolvedor para aprender o formato, eles podem escrever em qualquer formato sob o sol e ele parecerá automaticamente da maneira que todo mundo quer. Isso remonta ao ponto 2, onde você não aprende o estilo e ainda não consegue lê-lo corretamente.

Agora, posso estar inclinado a dizer que executar um formato automático em um projeto que está totalmente encerrado seria uma boa idéia. Isso iniciaria todos os desenvolvedores com o mesmo pé do projeto quando você corrigisse / adicionasse recursos posteriormente. Durante o desenvolvimento ativo, no entanto, acho que é uma escolha muito ruim.

Basicamente: coloque a responsabilidade do funcionário em aprender o estilo da empresa, não force o código a ser algo que não é.