Devo usar o ReSharper para arrumar código de outros povos?

Question

Eu uso ReSharper no trabalho. Alguns dos meus colegas não.

Quando eu abrir algum código que foi escrito alguém que não faz, é imediatamente óbvio pela quantidade de laranja na minha tela.

O que eu tenho a certeza de é até que ponto eu deveria me sentir livre para arrumar a bagunça a ter inadvertidamente deixados. Com a maioria do que eu estou olhando, ele é desleixado, mas inofensivo, e não seria realmente saltam em mim se eu nunca tinha usado ReSharper.

Eu acho que eu ver minhas opções amplamente como

1) A história de mudanças no código fonte é essencial para a manutenção. Alterar o mínimo possível, ou o próximo cara vai ter uma esperança de descobrir o que mudou. Quem se preocupa com código inacessível, o uso desnecessário de .ToString () etc. de qualquer maneira.

2) Alterar as coisas sem sentido como inclui, comentários de documentação método correção e coisas assim. O cara que escreveu que gosta de seu código para olhar como esta, para deixá-lo em um estado onde ele não vai reclamar, mas se livrar de algumas das laranja desnecessário

3) Laranja é apenas vermelho, mas mais leve. F12, em seguida, Alt + Enter até verde.

4) Esqueça a laranja, olhada essa função linha monstro 700. O que é este 1997? Hora de começar ocupado ... e se você tem o tempo, introduzir o seu colega para o nosso bom amigo e mentor Sr. Fowler.

I tendem a flit entre as opções, dependendo de quanto tempo eu tenho, até que ponto eu sou agora responsável pelo código, e como complexo os olhares de código (que pode me fazer ir para 1 ou 4 geralmente).

Parece que uma das 4 opções deve ser o que eu estou lutando por embora, mas não tenho idéia de qual deles

Answer 1

"Leave the campsite cleaner than you found it."

É o princípio de escoteiro. Se é "seu" código e eles mantê-lo em seguida, introduzindo pequenas limpeza-mudanças não deve ofendê-los, mas indo longe demais pode parecer rude ou que você pode ser tomada de forma eficaz a propriedade do código.

Answer 2

Sua equipe deve chegar a acordo sobre um padrão. Se alguém usa outra ferramenta, você pode encontrar-se em uma guerra de edição não intencional.

Mas se podemos todos concordar, então sim. Limpar o código que você vá.

Answer 3

I fazer uma verificação "reformatar" antes de alterar qualquer uma lógica real, desta forma você pode ver o que mudou.

Answer 4

refatoração Escusado é apenas isso - é desnecessário. Ele enche-se os logs de história de repositório e você pode introduzir bugs.

Se as coisas "sem sentido" (documentação, comentários, etc.) deve ser formatado uma determinada maneira, e não é até seus padrões de desenvolvimento, então eu faria tudo de uma vez em tão poucas checkins possível.

Quando você está realmente trabalhando sobre os pedaços de código e ter a oportunidade de testar as alterações, faça o refatoração então. ReSharper estará sempre disponível para lhe mostrar o caminho nesse ponto.

Answer 5

Se as ferramentas de desenvolvimento em sua equipe não são os mesmos, eventualmente, haverá ainda mais problemas. Siga a "reformatar" check-in sugerido acima e padronizar o conjunto de ferramentas com seus colegas, quer deixar cair o ReSharper ou dar a todos a magia formatação varinha.

Answer 6

Toda vez que você mudar alguma coisa, independentemente da intenção, o risco de quebrar alguma coisa sem querer. Em um lado pessoal, eu não iria alterar o código de outra pessoa sem falar com eles primeiro.

Answer 7

Eu recomendo mudando apenas as coisas quando você precisar. Há, é claro, alguma definição Variando ao que significa "necessidade". Por exemplo, se você escrever um método que chama outro método, e este método que você está chamando por acaso tem alguma duplicação de código? Eu refatorar isso, e enquanto eu estou nele remover o excesso de declarações using, etc. eu tentar evitar apenas um refactor maciça de toda a base de código "apenas porque" embora.

Answer 8

Se ele já fez, tenha cuidado. Algumas pessoas ficam muito sensível e é considerado rude se alguém em sua equipe ainda está usando ferramentas de uma década atrás, que não pode desativar a detecção de espaços em branco durante uma diff.

Em geral, eu vou limpar o código styling para trazê-lo em linha com os objetivos declarados estilo organização quando estou tocando o código por outro motivo. Tente lembrar-se que o estilo é estilo, no entanto, e como tal não há "único caminho verdadeiro." Não faça inimigos, porque você não gosta do fato de que um colega usos menos (ou mais) espaços em branco do que você.

Answer 9

A minha sugestão seria a de que se você fizer uma reformatação que ser feito em separado de quaisquer modificações no código. A razão para isso é que você pode marcá-lo como "única reformatar" no repositório e uma alteração de código legítimo não será enterrado no meio de um monte de espaçamento alterações tornando impossível para você ou o cara ao lado para descobrir o que quebrou .

Answer 10

Como a maioria das pessoas já disse, sim, melhor para refatorar e deixá-lo mais arrumado.

A refatoração ajuda a todos ficar melhor, e todos devem ter acesso às ferramentas de refatoração (CodeRush para mim).

No entanto, se seus colegas não estão compartilhando o amor refatoração, então é uma boa oportunidade para você esclarecê-los:)