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

16

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 ...

Tamara Wijsman
la source
9
Je suppose que vous avez un problème avec cela. Si oui, pourquoi? Est-ce que cela aggrave le code ?
Zaz
3
@Josh: Oui, en fait, cela aggrave le code, car il est plus difficile à maintenir par un autre programmeur que le gars qui l'a écrit.
Robert Koritnik
4
lui donner plus de travail à faire
Oscar Cabrero
4
@Robert - Je pense que vous manquez le point de @ Josh. Changer l'apparence du code peut le rendre objectivement plus facile à maintenir ... surtout s'il était mal formaté au départ.
Stephen C
4
Est-ce vraiment votre code ou appartient-il à l'équipe?
Eric King

Réponses:

28

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.

BlairHippo
la source
17
Il convient de noter que de nombreux IDE ont des fonctionnalités de formatage automatique. Je les utilise tout le temps sans y penser. Certains vont même formater tous les fichiers de votre projet ou tous les fichiers que vous avez ouverts, selon la façon dont il est configuré. Il peut être facile de formater accidentellement automatiquement.
Matt Olenik
@Matt: Excellent point.
BlairHippo
1
"Ils ne font pas ça ... parce qu'ils ont une forme de trouble obsessionnel-compulsif;" En parlant principalement de moi, ce n'est pas toujours le cas! En ce qui concerne le code, je suis deux choses: un perfectionniste et un monstre soigné. Malgré cela, je m'efforce généralement d'éviter d'appliquer cette mentalité au travail de mes collègues.
Nathan Taylor
5
Oh, je ne dis pas que le collègue de Tom n'est pas un obsédé du trouble obsessionnel-compulsif avec un mauvais sens des limites. Je dis juste que d'entrer dans une conversation avec un état d'esprit de "Qu'est-ce qui ne va pas avec vous?!" n'est pas un bon moyen d'avoir une conversation productive. :-)
BlairHippo
1
@Chris pas besoin de s'inquiéter de la justification, j'ai toujours Ctrl + K + D!
Nathan Taylor
16

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.

Adam Lear
la source
9

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 :)


la source
8

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.

Dan Dyer
la source
C'est votre lisibilité, je trouve que le code SQL non indenté est beaucoup plus facile à lire car je lis du code rapide et indenté qui me ralentit et me rend plus difficile la concentration.
HLGEM
6

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.

JeffO
la source
"Ou ils ont un TOC et peuvent avoir besoin de médicaments." - mieux vaut ne pas mentionner cette partie si vous voulez rester amical
Zaz
Je ferai un amendement.
JeffO
5

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.

Chinmay Kanchi
la source
5

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).

Dan Diplo
la source
1
"(Cependant, je ne le reformaterais pas s'il était soigné, mais pas à mon goût)" - règle très importante à suivre, +1
Zaz
Nos directives de développement ont tendance à mettre davantage le style de code dans le coin «recommandé». Je formate automatiquement le code selon les recommandations au niveau du fichier si je le trouve difficile à lire.
Joeri Sebrechts
3

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?

Daenyth
la source
2

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).

Wizard79
la source
2

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.

Ilia K.
la source
1

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». ;-)

tia
la source
0

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.

Robert Koritnik
la source
Je dois voter contre. StyleCop est une terrible mise en œuvre d'une idée décente. 1) Il s'exécute après la construction, ce qui en fait un tueur de temps majeur sur les grands projets 2) Ses règles par défaut contredisent en fait les valeurs par défaut de VS dans certains cas 3) Certaines des règles sont purement stupides. Il se plaint de "//" sans espace de fin et vous dit ensuite d'utiliser "////" à nouveau, après une compilation. C'est le pire. Ce ne serait pas mauvais, mais la partie après la construction vous tue vraiment sur un grand projet avec un long temps de construction.
MIA
Je ne serais pas d'accord avec vous sur de nombreux aspects que vous avez signalés. Vous pouvez configurer le fonctionnement de la vérification de style. J'ai même implémenté quelques règles qui fournissent le formatage que je souhaite. En ce qui concerne la vitesse, je ne peux pas dire que c'est génial. mais sur une machine décente, cela devrait fonctionner très bien. Pensez à la vitesse du copilateur C ++ au début des années 90 où vous étiez en mesure d'aller préparer une tasse de thé en attendant. Alors que votre build a échoué !!!!!! ;)
Robert Koritnik
Je viens de commencer à utiliser StyleCop pour voir comment ça se passe et même si c'est un peu ennuyeux parfois, cela aide également à trouver beaucoup d'erreurs qui autrement ne passeraient pas inaperçues. Vous n'avez pas besoin de l'exécuter dans le cadre de la génération et vous pouvez simplement l'exécuter sur votre ordinateur local, également pour des fichiers uniques uniquement. Vous pouvez donc l'utiliser sans gêner vos collègues développeurs. De plus, si vous n'aimez pas les règles, vous pouvez simplement les désactiver, donc pas de mal réel.
Anne Schuessler
+1 Il ne s'agit pas explicitement de StyleCop .. (StyleCop ou similaire ). Et c'est une très bonne idée. Définissez un ensemble de règles, configurez votre outil de choix et faites-en pour toujours.
Bruno Schäpper
Ces jours-ci, nous avons Grunt, Gulp, etc. qui peuvent faire cette étape comme StyleCop l'a fait dans le passé.
Robert Koritnik
0

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é

Junior M
la source