A imposição do mesmo formato de código para todos os desenvolvedores é uma boa ideia?

82

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 desenvolvedores (> 10), o que torna mais difícil para um desenvolvedor trabalhar no código de outro desenvolvedor. O mesmo arquivo Java, às vezes, usa três formatos diferentes.

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

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

    
por Stijn Geukens 05.03.2013 / 13:20
fonte

17 respostas

100

Atualmente, trabalho em um local onde um formato de código padrão é aplicado e o código é formatado automaticamente ao salvar o arquivo, exatamente como você está prestes a fazer. Como novo membro da empresa, descobri que as regras comuns de formatação me davam uma sensação calorosa e vaga de que "esses caras sabem o que estão fazendo", então eu não poderia estar mais feliz. Como uma nota secundária relacionada, com as regras de formatação comuns, também aplicamos determinadas configurações de aviso do compilador, bastante estritas, no Eclipse, com a maioria delas configuradas como Error, muitas definidas como Warning e quase nenhuma configurada como Ignore.

Eu diria que há dois motivos principais para impor um formato de código único em um projeto. Primeiro, tem a ver com o controle de versão: com todo mundo formatando o código de forma idêntica, todas as alterações nos arquivos têm a garantia de serem significativas. Não basta adicionar ou remover um espaço aqui ou ali, muito menos reformatar um arquivo inteiro como um "efeito colateral" de alterar apenas uma linha ou duas.

A segunda razão é que meio que tira os egos dos programadores da equação. Com todo mundo formatando o código da mesma maneira, você não pode mais dizer com facilidade quem escreveu o quê. O código se torna mais anônimo e comum, então ninguém precisa se sentir desconfortável em mudar o 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 sobre a formatação do código, já que o Eclipse fará isso 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 onde todos tiveram seus próprios estilos. Então você tem que pensar em questões estúpidas e sem sentido, como se não há problema em modificar o código de outra pessoa em seu próprio estilo, ou se você deveria tentar imitar seu estilo.

O único argumento contra as configurações comuns de formatação de código que eu posso imaginar para o seu caso é que aparentemente é um projeto já em andamento, por isso causará muitas mudanças desnecessárias em todos os arquivos, atrapalhando o histórico real dos arquivos. Na melhor das hipóteses, você pode começar a impor as configurações desde o início de um projeto.

    
por 05.03.2013 / 16:21
fonte
37

Todo desenvolvedor de software profissional preferirá adotar um padrão (bom) em vez de entrar em guerras evangélicas em vez de estilo, pelas mesmas razões que você delineou.

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

Dependendo da sua posição dentro da equipe e da dinâmica da equipe, você pode decidir que ganhar a guerra não é possível. Neste caso, pode ser melhor não começar ...

    
por 05.03.2013 / 09:49
fonte
30

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

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

Isso ajudará quando estivermos merging code no sistema 'Version control'.

    
por 05.03.2013 / 09:45
fonte
14

O que você está tentando ganhar, quão anal retentivo você vai estar em aplicá-lo (e no nível de detalhes suas "regras" serão estabelecidas), você vai tentar impor isso no código escrito em línguas diferentes, você vai tentar aplicá-lo retroativamente no código existente?

  1. uma aparência comum do código pode realmente ajudar a tornar o código mais legível, mas também pode piorar as coisas se a aparência e a aparência incorretas forem feitas. Notação _hUngarian_lpfstr sendo um excelente exemplo:)
  2. Eu vi "padrões de código" impondo o número de espaços de espaço em branco entre blocos de comentários, a ordem alfabética de nomes de métodos e outras bobagens. Não faça isso.
  3. Idiomas diferentes têm padrões diferentes para os quais as pessoas estão acostumadas em seu uso. Alguns até exigem esses padrões (pense que Python, Cobol, Visual Studio impõem automaticamente as convenções de bracing no estilo C ++, enquanto o Java usa o estilo C por convenção etc. etc.).
  4. nunca mude o código existente para alterá-lo, você só está introduzindo novos problemas dessa maneira. E isso significa seções de código, bem como arquivos de origem inteiros. Então não saia por aí reformatando o código existente quando alguém muda uma única linha em um arquivo de 1000 linhas.
  5. programadores experientes podem ser muito mais produtivos se não tiverem que 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 haja boas razões para impor um estilo e um padrão específicos, há boas razões para não fazê-lo (estritamente).

    
por 05.03.2013 / 14:21
fonte
11

Sim, a consistência é uma boa ideia, por motivos outros têm sentado .

Eu só queria adicionar alguns pontos que não foram usados em outro lugar:

  • A Oracle publicou conjunto de convenções para Java, que são o padrão de fato.
    • O uso desses recursos ajuda a evitar discussões sobre qual estilo seguir.
    • Muitas bibliotecas públicas e projetos de código aberto tendem a usar essas convenções, por isso, quando você precisa verificar se a formatação deve ser familiar.
    • O formatador do Eclipse possui regras internas para corresponder a essas convenções, o que também deve ajudar.
  • Você pode considerar a possibilidade de criar um gancho na configuração do controle de origem para que o código seja formatado automaticamente antes de entrar no ramo 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áximo de 80 caracteres por linha"), você só precisa fazer alterações em um só lugar.
por 12.04.2017 / 09:31
fonte
9

Eu estava em uma equipe que usava o plug-in Checkstyle . Em vez de usar os recursos prontos para uso, formamos um pequeno comitê de desenvolvedores interessados. Debatemos sobre o que parecia estar faltando, o que parecia excessivo e resolvemos as coisas. Todos aprendemos algo no processo e fortalecemos esses músculos de desenvolvimento.

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

Quando tivemos revisões de código, uma das primeiras perguntas foi: "Você passou pelo Checkstyle?" A conformidade com os padrões de codificação foi amplamente automatizada e chamou a atenção para o fato de o revisor ser exigente. Foi maravilhosamente fácil fazer Checkstyle realçar uma assinatura de método, clicar com o botão direito do mouse e alterar uma variável para final. Ele também poderia corrigir os recuos e chaves de modo que o código de todos tivesse uma aparência e comportamento semelhantes. Falta um Javadoc para uma função pública? Checkstyle irá marcar 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, impondo o mesmo formato e mais em encorajando uma aparência semelhante. E quando você está pastoreando gatos, uma ferramenta automatizada pode ajudar a aprimorar as habilidades e reduzir o cheiro do código sem machucar os egos frágeis.

    
por 05.03.2013 / 15:41
fonte
6

Se você vai se ater ao mesmo IDE e incorporar algumas ferramentas de formatação, é uma boa ideia, porque você não está precisando de muito esforço. Mantenha as regras simples com foco na legibilidade e não na retentividade anal . Essa deve ser a vara de medição.

Embora uma bola de lama consistentemente formada seja melhor do que apenas uma bola de lama, seu tempo seria melhor aproveitado em vez de ficar muito exigente sobre onde os suportes vão. Não se transforme no gerente com cabeça de alfinete que se sente como se estivesse fazendo seu trabalho contando espaços de recuo durante uma revisão de código junto com certificando-se de que o novas folhas de rosto estão nos Relatórios TPS .

Preferências pessoais são apenas isso e raramente melhoram a produção: link

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

    
por 23.05.2017 / 14:40
fonte
5

Eu recomendo strongmente que os humanos reforcem a formatação do código, e que pequenas infrações sejam graciosamente negligenciadas ou retocadas. 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 vai lidar com closures em Java, etc? Jalopy tem problemas com enums com funções de membro.
  2. Acho que é um fardo muito razoável colocar o programador para produzir 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 código deve ser formatado em todos os lugares. Sua empresa anterior pode ter escolhido um caminho diferente, e tudo bem. Não muito diferente da linguagem vernacular, existem idiomas específicos para sua cultura de código que você quer destacar.
  3. O cumprimento da sintaxe do código é melhor feito com revisões de código:
    1. Se a formatação for importante, ela atrairá sua organização para fazer revisões de código. Isso é de grande benefício.
    2. Se uma regra de formatação for quebrada, um ser humano pode examiná-la e julgar melhor do que uma máquina se a intenção for transmitida de maneira mais clara. 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 de código. A formatação de código pode ser uma ajuda, mas mentes diferentes analisam 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 como um único loop parece.

Eu não sou um grande fã de Domain Driven Design, 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 de um programa estruturado de Design Dirigido por Domínio. Mais uma vez ... eu não gosto de DDD, mas é um ótimo exemplo porque está bem definido.

Suponho que o tema dessa resposta seja Fazer revisões de código e deixar a formatação do fluxo da cultura e do processo de revisão.

    
por 05.03.2013 / 15:17
fonte
3

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

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 há regras gramaticais aplicáveis em 100% em inglês: nossos cérebros simplesmente não são conectados dessa maneira. Portanto, use as diretrizes, mas conceda aos desenvolvedores a liberdade de substituí-las da maneira que entenderem.

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

Mas tenha em mente que a formatação contribui muito menos para a legibilidade do que simplesmente como o código é logicamente organizado. Já vi muitos códigos de espaguete ilegíveis com formatação perfeita!

    
por 08.06.2013 / 21:02
fonte
1

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

Em um projeto específico em que eu estava, não havia convenções. Todo desenvolvedor fez as coisas do jeito deles. Por causa da relativa inexperiência desse time, ir de uma classe para a outra foi realmente chocante. O estilo era menos problemático do que o problema das convenções de nomenclatura. Um desenvolvedor faria referência a elementos da interface do usuário com uma terrível notação húngara (uma prática boba na era dos modernos IDE), nomearia membros privados de um jeito, outro nomearia de forma diferente. Você nunca soube o que estava vendo.

No extremo oposto, uma equipe usou o StyleCop (este foi um projeto .Net) como parte de seu processo de construçã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 de linha ou colocação de chaves, e a compilação iria vomitar por causa disso. Tanto tempo foi gasto apenas adicionando espaços e linhas às coisas, e todos, incluindo os caras que insistiram em usar o StyleCop, acabaram fazendo quase todos os commits. Foi uma enorme perda de tempo e dinheiro.

Então o ponto que estou fazendo aqui é que ser inflexível não é a resposta, mas estar no Oeste Selvagem também não é. A verdadeira resposta é 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 convenções ao vento.

    
por 09.06.2013 / 05:53
fonte
1

Meu principal argumento contra o estilo de codificação comum é 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 escreve um trecho de código uma vez e depois o lê de novo e de novo durante o desenvolvimento e a depuração. Se toda vez que ele ler seu próprio código, ele se esforça para entendê-lo desde que foi forçado a escrevê-lo em um estilo BAD, ele será muito infeliz e menos produtivo. Isso é da minha experiência.

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

Se a sua empresa vende código-fonte, o estilo de codificação é mais importante, mas se você vende código compilado, isso é muito menos relevante.

Esperar que o estilo de codificação torne o codificador original menos distinto e impeça as guerras do ego é besteira na melhor das hipóteses e simplesmente estúpido no pior dos casos. Grandes programadores sempre produzirão códigos elegantes, independentemente do estilo.

Eu também estou strongmente dando a cada desenvolvedor a propriedade de unidades de código específicas e evitando que todos toquem cada pedaço de código livremente. Desenvolver unidades inteiras no código e ser responsável por elas permite que o desenvolvedor tenha orgulho em seu trabalho e evite que ele desenvolva códigos ruins sabendo que os erros retornarão para caçá-lo.

Por fim, qualquer pessoa que tenha um estilo de codificação profissional sempre assumirá que seu próprio estilo de codificação será selecionado e todos os demais 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 do estilo de codificação?

    
por 09.06.2013 / 15:36
fonte
0

Bons desenvolvedores são pessoas criativas, dão a eles alguma licença artística. "Keep it simple" deve ser o mantra dos programadores. Eu tenho duas regras:

Regra 1: Forneça variáveis / cursores / objetos / procedimentos / qualquer NOME SENSÍVEL. Nomes não ambíguos que trazem significado e compreensão ao seu código.

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

É isso.

    
por 05.03.2013 / 21:55
fonte
0

Para mim, a principal vantagem de um formato comum aplicado automaticamente é que ele ajuda nosso controle de alterações & revisões de código. O git (e a maioria das outras ferramentas de controle de código-fonte) podem mostrar as diferenças das versões anteriores dos arquivos. Ao impor um estilo comum, isso minimiza a preferência do programador.

    
por 08.06.2013 / 19:21
fonte
0

Um formato para governar todos eles ... é realmente ótimo?

É como dirigir o carro de outra pessoa ...

Claro que você pode entrar e dirigir qualquer carro, mas estará mais seguro, mais confortável e terá menos chances de falhar se ajustar o assento, o volante e os espelhos para SEU preferência.

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

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

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

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

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

Tenha regras de formatação, mas permita alguma liberdade para aplicar o bom senso.

    
por 24.06.2013 / 23:03
fonte
-1

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

O Google publicou um artigo sobre isso chamado " Procurando por construir dívida: Experiências gerenciando a dívida técnica no Google ".

    
por 08.06.2013 / 20:58
fonte
-1

São idiomas e não códigos. Nós, humanos, temos mais de 6000 idiomas, então os traduzimos. Então, se você quiser que seus "códigos" se comuniquem, você terá que fazer seus ajustes. Você vê que os usuários precisam alterar nossos formatos de dados para que não percamos nossos dados.

    
por 09.06.2013 / 16:48
fonte
-2

Eu diria que não é. Uma estrutura / formato de código comum entre uma equipe é definitivamente uma coisa boa, mas aplicá-la automaticamente não é. Isso deve ser feito por humanos, não pelo computador.

Meus maiores problemas com o conceito são

  1. Se eu estou escrevendo código em um formato e ele é automaticamente reformatado, que incentivo há para realmente aprender esse formato?
  2. Seguindo esse ponto anterior, se você não aprender o formato, o ponto inteiro de autoformatação (para tornar o código mais fácil de ler e modificar) é completamente perdido. Você ainda precisa dedicar tempo para descobrir a formatação enquanto lê o código porque não aprendeu esse formato
  3. Eu acho que seria uma experiência chocante como desenvolvedor escrever uma aula um dia, fechá-la e voltar no dia seguinte para ver que é completamente diferente. Isso significa que não apenas os outros precisam aprender seu código, você precisa aprender seu código.
  4. Também poderia incentivar a codificação lenta. Em vez de empurrar o desenvolvedor para aprender o formato, eles podem escrever em qualquer formato sob o sol e automaticamente terão a aparência que todos desejam. Isso volta para o segundo lugar, onde você não aprende o estilo e ainda não consegue lê-lo corretamente.

Agora, posso estar inclinado a dizer que a execução de um formato automático em um projeto que está todo envolvido seria uma boa ideia. Isso iniciaria cada dev off no mesmo pé do projeto quando você for corrigir / incluir recursos mais tarde. 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 deles a ser algo que não é.

    
por 05.03.2013 / 20:50
fonte