Existe uma maneira de oferecer suporte a diferentes estilos de codificação em uma equipe de desenvolvimento

O Problema: Dois desenvolvedores => três opiniões sobre indentação, chaves em nova linha ou não, etc.

Geralmente trabalhamos com três ou quatro pessoas em nossos projetos e cada uma delas tem seu próprio estilo de código. Eu sei, a solução comum é concordar com um estilo de código que todo mundo precisa usar, mas não quero forçar programadores criativos de uma maneira que não se encaixe neles.

Portanto, a pergunta é: existe uma maneira de deixar cada programador viver seu próprio estilo, mas ter uma base de código comum dentro do repositório? Penso em algum plugin git / svn / any, que muda entre o estilo pessoal e o comum no checkout e no commit. Parece-me que a parte complicada dessa abordagem é oferecer suporte a diferenças corretas entre as versões de um arquivo

Não, você precisará fazer um padrão. Se você alterar o membro da equipe B (com uma ferramenta IDE automatizada ou manualmente), um monte inteiro de código do membro da equipe A gravado, que será confirmado e mostrado como uma alteração.

Isso é algo que quase toda equipe enfrenta e os padrões são "forçados" por esse mesmo motivo. Sugiro que você siga os padrões das autoridades linguísticas como linha de base e os adote de acordo com sua equipe.

Ter um estilo de codificação consistente também ajudará na manutenção do projeto e reduzirá a barreira de entrada para novas pessoas que trabalham no código.

Não, você precisará definir um padrão de codificação (de preferência um que já exista) e ter seus desenvolvedores aderidos a ele. Ser um programador profissional significa que você pode se adaptar a qualquer padrão de codificação usado no projeto em que está trabalhando.

SIM, pode funcionar desde que os estilos sejam sensatos e as pessoas não mudem o código de outras pessoas para corresponder às suas preferências e / ou misturar estilos em um único arquivo de código.
Não é o ideal, mas não é diferente de herdar código antigo criado para um "padrão" diferente do seu e ter que integrá-lo à sua base de código.
Portanto, se você precisar fazer isso, algumas diretrizes:

• sem alterar o código com um estilo diferente para corresponder às suas preferências, isso custa tempo e introduz bugs
• permaneça consistente em qualquer arquivo único. Portanto, se o estilo A foi usado para escrevê-lo inicialmente, todos usarão o estilo A ao modificá-lo
• crie um padrão comum para sua interface pública, portanto, para tudo o que é exposto ao exterior (e sim, outros subcomponentes de um sistema são externos).

A resposta curta é não.

Embora as opiniões devam ser valorizadas no trabalho, especialmente em um trabalho baseado em conhecimento, como o Desenvolvimento de Software, os desenvolvedores precisam perceber que uma opinião é apenas uma opinião e que eles existem para escrever um software que não discuta qual o melhor padrão de indentação de linha.

O objetivo de um documento de normas deve ser o de impor / sugerir um conjunto de normas / convenções comuns de codificação que abordem

1. Itens de layout, como tabulação, recuo, uso de {, (,
2. Nome da variável, do objeto e da função, ou seja, CamelCase, notação húngara
3. Manipulação de exceções como / quando / onde é realizada
4. Comentários de código. Você sempre faz referência a um documento de design, um número de bug etc.

Os documentos de normas ajudam a garantir que o código seja fácil de ler, manter e consistente em suas convenções.

Isso é inestimável ao revisar o código antes dos checkins, depurar alguém ou modificar o código vários anos depois que o desenvolvedor original deixou a empresa.

Normalmente, ao criar um documento de Padrões de codificação, reviso os padrões do setor para o idioma que estou usando (C, C #, SQL), uso os padrões mais apropriados, circulo para os desenvolvedores mais experientes / influentes para comentar, incorporo os comentários quando apropriado e depois libere o documento.

A reformatação automática do código antes que ele seja comprometido com o seu sistema de controle de versão é possível em teoria.

No entanto , há um grande problema: as ferramentas de formatação automática de código não são 100% confiáveis. Assim, você pode realmente introduzir problemas no seu código com este sistema. Na minha opinião, isso mata a ideia. É sempre mais importante ter código funcional do que código com estilo adequado!

Se o projeto for compartimentado e a maior parte do código tender a "pertencer" a programadores individuais, pode ser bom deixá-los usar seus próprios estilos (dentro do razoável). No entanto, se várias pessoas estiverem trabalhando frequentemente no mesmo trecho de código, provavelmente será necessário aplicar um estilo.

Aqui está uma discussão semelhante sobre o estouro de pilha .

O código unidirecional de reformatação automática pode ser uma solução viável se você:

1. Encontre um autoformador que realmente funcione para a convenção que você deseja implementar e sua linguagem de programação.
2. É possível fazer o pré-commit para que a reformatação não apareça nos logs de alterações misturados e indistinguíveis das alterações funcionais reais.
3. Consiga que sua equipe chegue a um acordo sobre qual convenção deve ser aplicada (porque, de um modo geral, não há "caminho de volta" no check-out para a preferência pessoal de um desenvolvedor, pelo menos não que eu saiba).

Nenhum desses é realmente fácil de fazer em muitos casos, então considere escolher suas batalhas aqui! Vi equipes fazerem isso com êxito em um projeto C # / .NET em que a reformatação já aconteceu no PC do desenvolvedor, portanto é possível em algumas circunstâncias.

absolutamente você pode. É tudo sobre não suar as pequenas coisas.

O único padrão importante é "manter suas alterações no mesmo estilo que o código existente". Contanto que você possa se adaptar a um estilo de codificação que não seja o seu preferido, poderá trabalhar com qualquer estilo de codificação.

Então, qual é o problema de trabalhar em três estilos diferentes na mesma empresa. Seus desenvolvedores precisam entender isso, que a escrita do código da maneira que eles gostam é encontrada para o código, mas depois que fazem alterações em um arquivo diferente que usa um estilo diferente, eles precisam manter esse estilo (ou ficará realmente ruim) . Não é permitida a reformatação (ou elas serão reformatadas continuamente e as diferenças do scm serão inúteis) (e se você fizer isso, deverá ser empregado um formatado automaticamente).

As chances são de que, assim que chegarem a esse ponto, eles chegarão a um consenso sobre qual estilo usar ou o estilo que derramarão na maior parte do tempo. Se eles vão ser infantis sobre isso e reformatam o código um do outro o tempo todo, é hora de baixar um padrão da Internet e exigir que eles o usem. Você pode fazer isso de qualquer maneira, apenas para acenar na cara deles como um cartão de "jogar bem ou não".