Formatar código de maneira ruim ao usar um VCS?

Quase sempre formato meu código antes de me comprometer para garantir que ele seja feito corretamente. A maioria da minha equipe realmente não se importa e nem sempre formata seu código adequadamente (pequenas coisas que não afetam o código, mas afetam a legibilidade ao tentar mantê-lo).

Eu instalei recentemente as ferramentas avançadas do VS que possuem a opção "Formatar ao salvar" e fiz uma alteração em um arquivo que não foi formatado anteriormente. O vice-presidente de desenvolvimento veio até mim e me repreendeu pela formatação, pois aparece na ferramenta de mesclagem como tendo quase todo o arquivo alterado, em vez de apenas uma linha ou duas (para que ele não possa ver exatamente o que eu modifiquei facilmente) e me disse para desativar o formato ao salvar no futuro. Embora eu entenda essa preocupação, às vezes acho difícil classificar o código não formatado e, na IMO, ele deve ser formatado adequadamente o tempo todo. Observe que não estou apenas reformatando as coisas por um capricho., Mas enquanto escrevo código, usarei a ferramenta elétrica ou pressionarei o comando key para formatar o texto para facilitar a leitura, e no SVN isso aparece como uma modificação.

Então eu pergunto, sempre a formatação do código é realmente uma coisa ruim? Suas preocupações são mais válidas do que garantir que o código seja legível?

Primeiro, sua equipe precisa escolher uma convenção de formatação e cumpri-la. Você precisa chegar a um acordo e fazer com que todos cumpram, para que não haja pessoas brigando pelo que as coisas deveriam ter. Isso não deve ser apenas algo que você faz por conta própria.

Quanto à sua verdadeira pergunta. Formatar código não é uma coisa ruim. O que é ruim é fazer grandes alterações de formatação no mesmo commit das alterações de código. Quando sua equipe chegar a um consenso sobre como as coisas devem ser formatadas, faça uma passagem pelo código e formate tudo. Verifique isso por si só. A mensagem de confirmação deixará claro que as alterações são apenas espaços em branco e não funcionais. Então, quando você precisar fazer alterações funcionais, elas estarão em um commit diferente para que possam ser vistas claramente.

Não, o código de formatação é muito importante . No entanto, as confirmações devem ser feitas em dois grupos:

1. Alterações cosméticas - qualquer coisa que torne o código mais legível.
2. As outras mudanças - tudo o mais que afeta o código.

Use a mensagem de confirmação para indicar que apenas cosméticos foram alterados. Eles podem ser facilmente ignorados ao procurar modificações mais substanciais.

Vocês dois têm razão, mas podem conseguir o que querem. Formate o código primeiro, verifique apenas essa alteração. Em seguida, faça as alterações funcionais e faça o check-in como uma segunda etapa.

Também sou um seletor de formatação, então aqui estão algumas dicas:

• Primeiro passo necessário: peça à equipe que chegue a um acordo sobre alguns padrões básicos de formatação, como guias versus espaços, posições entre parênteses, estilos de comentários etc. Agora, suas alterações de formatação não serão uma surpresa completa para todos, e você não irá nos dedos dos pés.

• Limpe a formatação apenas em torno do código que você altera. Se você fizer alterações em apenas uma função, limpe essa função. Pelo menos com o tempo, você terá um código mais bonito.

• Faça grandes revisões de formatação como uma confirmação separada, sem outras alterações de código. Você só deve fazer isso quando tiver menos probabilidade de comparar o código após a alteração com antes da alteração, pois comparar um diff como esse pode ser irritante. Eu costumo fazer limpezas como a primeira coisa antes de um grande desenvolvimento nesse código.

• Obtenha uma boa ferramenta de diferenciação que possa fazer marcações dependentes do idioma de alterações significativas e não significativas. Meu diff também favorito Beyond Compare marca as alterações reais do código em uma cor e as diferenças de espaço em branco / comentário apenas em outra.

edite para mais uma dica:

• Isso varia de idioma para idioma, mas, para as alterações mais cosméticas do código, você deve comparar os binários compilados antes e depois de uma limpeza importante para ter certeza absoluta de que não estragou tudo.

Você não deve reformatar a formatação e confirmar alterações no código de outras pessoas, a menos que:

• você é o gerente que está tentando estabelecer padrões de codificação de equipe
• seu gerente solicitou que você limpe o código para aderir aos padrões de codificação da equipe
• você está limpando o código de um desenvolvedor que não está mais em sua equipe para aderir aos padrões de codificação da equipe.

Você notará em todos os casos que me refiro aos padrões de codificação da equipe. Acredito firmemente em padrões de codificação razoáveis ​​e acordados para a equipe. Se você os possui, o desenvolvedor original deve voltar e limpar seu código para aderir aos padrões da equipe, não o faça pelas costas. Se você não possui padrões (e deveria), não deve modificar o código de outro membro da equipe para aderir às suas filosofias, principalmente pelas costas. Lembre-se de que você faz parte de uma equipe e, embora os padrões de codificação sejam importantes, a confiança e o respeito entre os membros da equipe também são importantes.