Dois-je utiliser ReSharper pour ranger le code d'autres peuples?

Question

J'utilise ReSharper au travail. Certains de mes collègues ne le font pas.

Quand j'ouvre un code qui a été écrit quelqu'un qui n'a pas, il est immédiatement évident par la quantité d'orange sur mon écran.

Ce que je ne suis pas sûr de est dans quelle mesure je devrais me sentir libre de ranger les dégâts l'ont, sans le savoir à gauche. Avec la plupart de ce que je suis à la recherche, il est bâclée, mais inoffensif, et ne pas sauter vraiment à moi si je ne l'avais pas déjà utilisé ReSharper.

Je suppose que je vois mes options au sens large comme

1) L'historique des modifications apportées au code source est essentielle à l'entretien. Changer aussi peu que possible, ou le prochain gars ont l'habitude d'un espoir de déterminer ce qui a changé. Qui se soucie de code inaccessible, l'utilisation inutile de .ToString (), etc. de toute façon.

2) Changer les choses sens comme inclut, corriger les commentaires de documentation des méthodes et des choses comme ça. Le gars qui a écrit aime son code comme cela, donc le laisser dans un état où il se plaint coutume, mais se débarrasser de certains de l'orange inutile

3) Orange est juste rouge, mais plus léger. F12 puis Alt + Entrée jusqu'à ce que vert.

4) Oubliez l'orange, regardez ce monstre 700 fonction de la ligne. Qu'est-ce que ce 1997? Il est temps de se mettre au travail ... et si vous avez le temps, présenter votre collègue à notre bon ami et mentor M. Fowler.

Je tends à voltiger entre les options en fonction de combien de temps j'ai, dans quelle mesure je suis maintenant responsable du code, et la complexité de l'apparence de code (qui peut me faire aller pour 1 ou 4 habituellement).

Il semble que l'une des 4 options devrait être celui que je suis pour que efforçais, mais je ne sais pas que l'on

Answer 1

"Leave the campsite cleaner than you found it."

Il est le principe de boyscout. Si c'est « leur » code et ils maintiennent l'introduction puis peu nettoierons changements ne devraient pas les offenser, mais aller trop loin peut sembler grossier ou vous pourriez prendre effectivement la propriété du code.

Answer 2

Votre équipe doit se mettre d'accord sur une norme. Si quelqu'un d'autre utilise un autre outil, vous pouvez vous retrouver dans une guerre d'édition non intentionnelle.

Mais si vous pouvez tous d'accord, alors oui. Nettoyer le code que vous allez.

Answer 3

Je fais un « reformater » check-in avant de modifier la logique réelle, de cette façon vous pouvez voir ce qui a changé.

Answer 4

Il va refactoring est juste que - inutile. Il encombre les journaux d'historique du référentiel et vous pouvez introduire des bogues.

Si les choses « sans signification » (documentation, commentaires, etc.) est censé être formaté d'une certaine façon, et ce n'est pas à vos normes de développement, alors je le ferais à la fois en peu de checkins possible.

Lorsque vous travaillez la présence des morceaux de code et que vous avez la possibilité de tester vos modifications, faites-le refactoring alors. ReSharper sera toujours disponible pour vous montrer le chemin à ce moment-là.

Answer 5

Si les outils de développement de votre équipe ne sont pas identiques à terme, il y aura encore plus de mal. Suivez le « reformater » check-in suggéré ci-dessus et de normaliser le jeu d'outils avec vos collègues, soit déposer ReSharper ou donner à chacun la mise en forme de baguette magique.

Answer 6

Chaque fois que vous changez quoi que ce soit, quelle que soit l'intention, vous risquez de casser quelque chose sans le vouloir. Sur un plan personnel, je ne changerais pas sans parler de leur code d'une autre personne d'abord.

Answer 7

Je recommande que changer les choses quand vous avez besoin. Il y a, bien sûr, une définition variable sur ce « besoin » signifie. Par exemple, si vous écrivez une méthode qui appelle une autre méthode, et cette méthode que vous appelez arrive à avoir une certaine duplication de code? Je Refactor que, et pendant que je suis à elle supprimer des déclarations excès de using, etc. Je vais essayer d'éviter juste un refactoring massif de l'ensemble codebase « juste parce que » bien.

Answer 8

Si elle est déjà cochée dans, soyez prudent. Certaines personnes ont terriblement chatouilleux et il est considéré impoli si quelqu'un de votre équipe utilise toujours des outils d'il y a une dizaine d'années qui ne peuvent pas désactiver la détection des espaces lors d'une diff.

En général, je vais nettoyer le style de code pour la mettre en conformité avec les objectifs de style organisation a déclaré quand je touche le code pour une autre raison. Essayez de vous rappeler que le style est le style, cependant, et en tant que tel il n'y a pas « d'une façon vraie. » Ne pas faire des ennemis parce que vous ne voulez pas le fait qu'un collègue utilise moins (ou plus) des espaces que vous.

Answer 9

Ma suggestion serait que si vous faites un reformatage que cela soit fait séparément de toutes les modifications de code. La raison de ceci est que vous pouvez le marquer comme « reformater seulement » dans le référentiel et un changement de code légitime ne sera pas enterré au milieu d'un tas de changements d'espacement rendant impossible pour vous ou le gars à côté de comprendre ce qui a brisé .

Answer 10

Comme la majorité des gens ont déjà dit, oui, mieux refactorisons et le laisser tidier.

Refonte aide tout le monde aille mieux, et tout le monde devrait avoir accès aux outils de refactoring (CodeRush pour moi).

Toutefois, si vos collègues ne partagent pas l'amour de refactoring, il est une bonne occasion pour vous de les éclairer:)