Que faire si un collègue modifie votre code juste pour changer l'apparence?

Que devez-vous faire si un collègue modifie votre code?

Sans but d'ajouter des fonctionnalités ou de corriger des bugs, juste pour changer à quoi ça ressemble ...

Parlez-en avec eux. Entrez dans la conversation avec l'attitude de "Ils ne font pas cela pour m'ennuyer ou parce qu'ils ont une forme de trouble obsessionnel-compulsif; ils essaient d'améliorer mon code."

Parce que vous pourriez vous tromper. Cela pourrait être une correction de bogue subtile et vous ne l'avez tout simplement pas repérée.

Ou, il se pourrait qu'il y ait une norme de codage que vous ne connaissez pas que vous violez, et ils la corrigent simplement.

Ou, il se peut qu'ils essaient de vous ennuyer, ou qu'ils souffrent d'une forme de trouble obsessionnel-compulsif. Si c'est le cas, demandez-leur gentiment d'arrêter, et si cela ne fonctionne pas, discutez-en avec votre patron.

Mais vous ne saurez jamais à moins que vous ne le demandiez.

Je ne suis pas tellement marié à la façon dont mon code le recherche pour me déranger. :) J'essaie d'apprendre des changements. Mon collègue a-t-il ajusté les noms des variables? Écrire une boucle plus efficace? Rendre le code plus lisible?

Si je ne vois pas comment les changements ont amélioré ce qui était déjà là, je demande généralement au collègue qui a apporté les changements quelle était la motivation derrière eux. Il est possible que l'avantage ne soit tout simplement pas évident pour moi. Et si j'ai raison et qu'ils ont tort, je peux peut-être expliquer pourquoi je l'ai écrit comme je l'ai fait.

Si tout le reste échoue, annulez l'enregistrement. ;)

Edit: Tous les paris sont désactivés si le désir de faire des changements cosmétiques introduit un bug, cependant.

IMO vous et votre équipe devriez utiliser une norme de codage de toute façon. Si tel est le cas, la question devient alors "votre code d'origine était-il conforme à la norme?" Si «oui», votre collègue ne devrait pas toucher votre code, sauf pour le modifier de manière fonctionnelle. Si «non», je crains que votre collègue ait le droit de ranger votre code. En tant que chef de projet, je me retrouve à le faire tout le temps.

Si vous n'utilisez pas de norme de codage, tout l'argument de ce qui constitue un «bon code» devient beaucoup trop subjectif. C'est pourquoi vous devriez utiliser une norme de codage :)

Comme l'un de ceux personnes (les personnes qui reformatent parfois le code d'autres personnes), la principale raison pour laquelle je le fais est la lisibilité. Certaines personnes sont tout simplement extrêmement bâclées avec leur indentation ou avec des onglets et des espaces de mélange.

La principale chose que j'ai l'habitude de changer est de réduire les longues lignes afin de pouvoir lire le tout sans défilement horizontal. Je vais décomposer des instructions complexes en instructions distinctes ou reformater les appels / déclarations de méthode pour répertorier un paramètre par ligne s'il ne tient pas tous confortablement sur une seule ligne. Je vais également modifier les commentaires, soit pour corriger les erreurs anglaises, soit pour clarifier les choses.

Oui, je pourrais le laisser tranquille, mais je préférerais réduire l'effort mental requis pour lire le code.

Que devriez-vous faire à ce propos? Tout d'abord, considérez que cette personne améliore peut-être votre code. De plus, vous devez vous assurer d'avoir un certain consensus dans votre équipe sur la façon dont le code doit être formaté. Si chaque personne a des habitudes différentes, cela ralentira tout le monde. S'ils n'améliorent pas votre code et qu'ils vont à contre-courant, vous devez les confronter à ce sujet. Si cela ne fonctionne pas, vous devrez peut-être impliquer d'autres personnes.

Demandez-leur pourquoi ils le font; une explication valable peut diminuer votre frustration, mais vous devez leur faire savoir à quel point cela vous dérange. Qui sait, peut-être pensaient-ils qu'ils vous rendaient service et s'arrêteront lorsqu'ils apprendront que cela vous offense. Ou vous avez peut-être affaire à quelqu'un qui souffre véritablement d'une condition médicale.

Est-il autorisé à le faire? Les modifications améliorent-elles le code? Si oui, ravalez votre fierté. Si vous pensez que la qualité du code est détériorée, discutez-en avec le collègue et demandez-leur pourquoi ils ont ressenti le besoin de changer votre code sans aucun avantage évident. Si cela se fait par méchanceté ou parce que la personne se sent par erreur meilleure que vous et que vous ne pouvez pas vous en occuper, discutez-en avec votre patron.

Les IDE comme Visual Studio ont une option appelée Format Documentqui formatera le code selon les règles que l'utilisateur a définies dans l'IDE. Il se peut que votre collègue l'utilise (soit automatiquement sans le savoir, soit par application délibérée). Peut-être que leur IDE utilise des espaces au lieu des tabulations, ou vice versa, et ceux-ci sont appliqués automatiquement sans même le savoir? Mais vous devez leur parler pour le savoir.

Soit dit en passant, je reformaterai souvent le code de mes collègues s'il ne suit évidemment pas une sorte de schéma de formatage (c'est-à-dire qu'il est partout). C'est une manière, espérons-le, subtile de les faire remarquer. (Cependant, je ne le reformaterais pas s'il était soigné, mais pas à mon goût).

S'il le modifie pour qu'il réponde aux normes de codage de votre équipe, vous devriez suivre les normes la prochaine fois.

S'il le change de telle sorte qu'il ne respecte plus les normes de codage de votre équipe, informez-le de ce qu'il fait de mal et demandez-lui de le modifier à nouveau.

... Votre équipe dispose d'un ensemble de normes de formatage de code qui sont utilisées par tout le monde, non?

Je réorganise de temps en temps du code écrit par des collègues en désordre (ou corrige des fautes de frappe dans les commentaires). Ils savent que je suis obsédé par la mise en forme et l'ordre du code et donc ils me laissent faire ça sans trop me plaindre. Parfois, ils me donnent également un soda ou un cookie gratuit.

Bien sûr, ce travail est occasionnel , car il a brisé la fonctionnalité "blâme" dans SVN.

C'est aussi un moyen très simple de faire une sorte de révision de code (je lis généralement la plupart du code commis par mes collègues dans les modules sur lesquels je travaille).

Les conventions de code sont la réponse. Vous devriez en avoir un au travail. Si vous ne le faites pas, commencez dès maintenant (un bon point de départ est le guide de style Google ). Lorsqu'il existe des règles écrites (ou du moins communément connues), la réponse à votre question est triviale.

Je pense que vous pensez que c'est offensant de le faire ...? Par exemple, je corrigerais moi-même immédiatement ce code

int myFunction( ) {

    int i ;
  return  0;

}

devenir

int myFunction() {
    int i;
    return 0;
}

alors ... devrais-je être puni à cause de mon action? Dans la vraie vie, j'ai en fait des tonnes de journaux SVN lus «Formatage». ;-)

Utilisez un outil de vérification de style

Commencez à utiliser StyleCop ou similaire et appliquez des règles de style de code et faites également obligation à tous les développeurs de l'utiliser. Tout le code sera identique sans exception. Et réunissez-vous avec des sages pour discuter des règles les plus appropriées pour votre organisation. Même si les règles par défaut sont déjà très similaires au code du framework .net lui-même.

C'est la façon la plus simple de le faire. Je me suis retrouvé à corriger le code de quelqu'un d'autre chez l'un de mes précédents employeurs parce que cet autre gars écrivait du code avec des quantités excessives de lignes vides et aucune règle d'indentation. Le code était en fait illisible par un développeur moyen. Si StyleCop existait à l'époque, cela rendrait beaucoup d'entre nous très heureux.

c'est une pensée que j'ai vue sur Internet parler de refactoring et peut-être expliquer pourquoi quelqu'un toucherait votre code pour le rendre meilleur:

Pourquoi?

Il y a deux raisons principales de refactoriser:

1. Pour améliorer le code / la conception avant de construire dessus, il est vraiment difficile de trouver du bon code du premier coup. La première tentative d'implémentation d'une conception initiale nous montrera que nous avons mal interprété ou oublié une logique.

2. Pour s'adapter aux changements des exigences. Le changement se produit dans le développement logiciel; être réactif au changement est préférable d'avoir une bonne base de code. Nous avons deux options pour les deux scénarios, acheminer le code ou le refactoriser. Corriger le code nous mènera à un code non maintenable et augmentera notre dette technique, il est toujours préférable de refactoriser.

Quand?

1. Le plus tôt sera le mieux car c'est plus facile.

2. plus rapide et moins risqué de refactoriser un code récemment remanié plutôt que d'attendre de refactoriser que le code soit presque terminé.

Quelle?

1. Tout le code et tout le design sont candidats à la refactorisation.

2. Une exception pour ne pas refactoriser quelque chose pourrait être un morceau de code de travail dont la qualité est faible, mais en raison d'un délai proche, nous préférons garder notre dette technique plutôt que de risquer la planification.

Vous n'avez qu'à le laisser faire de son mieux, si ce serait génial pour les deux et vous faire gagner du temps à l'avenir!

à votre santé