Formatage de code une mauvaise chose lors de l'utilisation d'un VCS?

24

Je formate presque toujours mon code avant de m'engager pour m'assurer qu'il est fait correctement. La plupart de mon équipe ne se soucie pas vraiment et ne formate pas toujours correctement leur code (des choses mineures qui n'affectent pas le code mais affectent la lisibilité lorsque vous essayez de le maintenir).

J'ai récemment installé les outils électriques VS qui ont une option "Formater lors de l'enregistrement", et j'ai apporté une modification à un fichier qui n'a pas été formaté auparavant. Le vice-président du développement est venu me voir et m'a réprimandé pour le formatage car il apparaît dans l'outil de fusion comme ayant presque tout le fichier modifié, au lieu d'une ou deux lignes (il ne peut donc pas voir exactement ce que j'ai modifié facilement), et m'a dit de désactiver le format lors de la sauvegarde à l'avenir. Bien que je comprenne cette préoccupation, je trouve parfois difficile de trier le code qui n'est pas formaté, et l'OMI devrait être formaté correctement tout le temps de toute façon. Notez que je ne reformate pas simplement des choses sur un coup de tête. Mais comme j'écris du code, je vais soit utiliser l'outil électrique, soit appuyer sur le raccourci clavier pour formater le texte pour le rendre plus facile à lire, et dans SVN cela apparaît comme une modification.

Je demande donc, est-ce que le formatage du code est toujours une mauvaise chose? Ses préoccupations sont-elles plus valables que de s'assurer que le code est lisible?

Allan Wight
la source
8
il a raison, alors pourquoi ne pas demander à toute l'équipe d'utiliser l'outil de formatage lors de l'enregistrement, alors vous obtiendrez tous du code joliment formaté, facile à lire et à visualiser.
gbjbaanb
12
La plupart des bons outils de comparaison de fichiers ont un filtre pour les «différences sans importance» ou «ignorer les espaces blancs». Certains, comme Beyond Compare, sont livrés avec des filtres spécifiques au langage prédéfinis. Utilisez-le à votre avantage si vous l'avez.
Michael K
7
La mise en forme du code est aussi importante que les modifications apportées. La lisibilité doit être l'une des plus hautes priorités lorsque vous faites partie d'une équipe. Votre vice-président doit le savoir et s'en préoccuper.
Edgar Gonzalez
@Edgar: +1. Le VP est trop pointilleux. La lisibilité d'abord ... et une option Ignorer les espaces signifie que ce n'est pas grave. Et cela signifie également qu'il y a un problème plus important parce que le reste de l'équipe s'en fiche. Le VP devrait s'en préoccuper davantage.
quick_now

Réponses:

41

Tout d'abord, votre équipe doit choisir une convention de mise en forme et la respecter. Vous devez vous mettre d'accord et faire en sorte que tout le monde s'y tienne afin que personne ne se dispute à quoi les choses devraient ressembler. Cela ne devrait pas être quelque chose que vous faites vous-même.

Quant à votre vraie question. Le formatage du code n'est pas une mauvaise chose. Ce qui est mauvais, c'est de faire des changements de formatage majeurs dans le même commit que les changements de code. Lorsque votre équipe parvient à un consensus sur la façon dont les choses doivent être formatées, faites un passage dans le code et formatez tout. Vérifiez cela par lui-même. Le message de validation indiquera clairement que les modifications ne sont que des espaces blancs et ne sont pas fonctionnelles. Ensuite, lorsque vous devez apporter des modifications fonctionnelles, elles sont dans un commit différent afin qu'elles soient clairement visibles.

unholysampler
la source
cela n'aide toujours pas si vous voulez comparer les changements d'il y a plusieurs révisions, mais c'est mieux que le changement de code + les changements de format en une fois. Bien entendu, cette réponse s'applique également au refactoring.
gbjbaanb
1
+1: En plus de cela, il est bon d'utiliser quelque chose comme Stylecop ou un autre outil qui met en forme automatiquement et applique le style. Ensuite, synchronisez les paramètres entre tous les membres de l'équipe afin que la mise en forme soit cohérente pour tout le monde et que vous n'ayez pas nécessairement à vous rappeler quelle est la "bonne" règle de format.
Ryan Hayes
3
Si l'OP a été réprimandé pour avoir essayé de formater un document, quelque chose me dit qu'il ne pourrait pas suggérer d'utiliser StyleCop.
Wayne Molina
3
@gbjbaanb: Oui. C'est pourquoi il est préférable de prendre ce type de décisions au départ. Le projet sur lequel je suis maintenant a les paramètres du formateur Eclipse vérifiés dans le référentiel, donc nous savons que tout le monde a les mêmes paramètres.
unholysampler
1
@quickly_now: C'est pourquoi nous avons des gestionnaires avec droit de veto. Si les gens ne sont pas d'accord, ils peuvent prendre une décision.
unholysampler
29

Non, le formatage du code est très important . Cependant, les commits doivent être effectués en deux groupes:

  1. Changements cosmétiques - tout ce qui rend le code plus lisible.
  2. Les autres changements - tout ce qui affecte le code.

Utilisez le message de validation pour indiquer que seuls les cosmétiques ont été modifiés. Ceux-ci peuvent être facilement ignorés lors de la recherche de modifications plus substantielles.

JK
la source
3
En outre, il est également recommandé de décider d'une certaine convention de mise en forme entre votre équipe. Ne vous contentez pas de formater le code d'autres personnes sans en discuter d'abord.
Steven Jeuris
Ouais .. Mais vous savez, parfois c'est tellement tentant de formater ce foutu bordel "pendant que vous y êtes". De plus, essayer de séparer les changements cosmétiques des changements fonctionnels peut être pénible si vous utilisez VS et qu'il formate quelque chose automatiquement. Oh, et personne ne dira que vous faites un formatage stupide pendant que vous avez des tâches très importantes à faire en consultant l'historique des validations
Dyppl
10

Vous avez tous les deux un point, mais vous pouvez tous les deux obtenir ce que vous voulez. Formatez d'abord le code, archivez uniquement cette modification. Ensuite, apportez vos modifications fonctionnelles et vérifiez-les dans un deuxième temps.

PeterAllenWebb
la source
3
Je pense que c'est la meilleure solution pour votre situation actuelle, mais vous devriez en parler avec votre équipe. Cependant, vous avez un problème plus important, qui est l'absence de norme de codage.
Thomas Owens
2
D'accord. Je me demande si l'environnement de l'OP est l'un de ces lieux de cow-boy où les normes sont évitées pour "faire avancer les choses rapidement".
Wayne Molina
4

Je suis également un formateur de mise en forme, voici donc quelques conseils:

  • Première étape requise: faire en sorte que l'équipe se mette d'accord sur une norme de mise en forme de base, comme les tabulations par rapport aux espaces, les positions des accolades, les styles de commentaire, etc. sur tous les orteils.

  • Nettoyez la mise en forme uniquement autour du code que vous modifiez. Si vous apportez des modifications à une seule fonction, nettoyez cette fonction. Au moins avec le temps, vous aurez un code plus beau.

  • Effectuez des révisions de formatage majeures en tant que validation distincte, sans autres modifications de code. Vous ne devriez le faire que lorsque vous êtes moins susceptible de vouloir comparer le code après la modification à avant la modification, car la comparaison entre des différences comme celle-ci peut être ennuyeuse. Je fais habituellement des nettoyages comme première chose avant un développement majeur sur ce code.

  • Obtenez un bon outil de différenciation qui peut effectuer le marquage dépendant de la langue des changements importants et des changements non significatifs. Mon diff préféré aussi Beyond Compare marque les changements de code réels dans une couleur et les espaces / commentaires uniquement les différences dans une autre.

modifier pour un autre conseil:

  • Cela varie d'un langage à l'autre, mais pour la plupart des modifications cosmétiques du code, vous devriez pouvoir comparer les binaires compilés avant et après un nettoyage majeur pour être absolument sûr de ne pas l'avoir fait.
John
la source
Tant que vous n'incluez pas de balises VC dans le binaire (ou des informations de build).
Vatine
2

Vous ne devez pas reformater et valider les modifications apportées au code d'autres personnes, sauf si:

  • vous êtes le gestionnaire qui tente d'établir des normes de codage d'équipe
  • votre responsable vous a demandé de nettoyer le code pour respecter les normes de codage de l'équipe
  • vous nettoyez le code d'un développeur qui ne fait plus partie de votre équipe pour respecter les normes de codage de l'équipe.

Vous remarquerez dans tous les cas que je me réfère aux normes de codage d'équipe. Je crois fermement en des normes de codage raisonnables et convenues pour l'équipe. Si vous les avez, alors le développeur d'origine devrait revenir en arrière et nettoyer son code pour adhérer aux normes de l'équipe, vous ne devriez pas le faire derrière son dos. Si vous n'avez pas de normes (et vous devriez), vous ne devriez pas modifier le code d'un autre membre de l'équipe pour adhérer à vos philosophies, en particulier derrière son dos. N'oubliez pas que vous faites partie d'une équipe et que les normes de codage sont importantes, il en va de même de la confiance et du respect entre les membres de l'équipe.

cdkMoose
la source
"Derrière leur dos": cela remonte aux problèmes psychologiques de la propriété du code (ou du développement de la guerre de territoire).
rwong
2
«Code d'autrui» est une façon intéressante de le dire. Je travaille sur le produit de mon entreprise, compilé à partir du code que possède mon entreprise, sur lequel les membres de mon équipe et moi travaillons. Il n'est en aucun cas derrière leur dos de le fixer aux normes tout en y travaillant. Cependant, je conviens que la solution idéale est de faire en sorte que le développeur d'origine le nettoie conformément à la norme.
Caleb Huitt - cjhuitt
@Caleb: devient difficile s'ils refusent tout simplement.
quick_now
Par «code d'autrui», je ne parle pas de propriété, je veux dire quelque chose qu'ils ont écrit et je pense qu'ils sont toujours responsables du soutien. En l'absence de normes de codage, si j'implémente une classe avec 1000 lignes de code et que vous apportez des modifications à 2 lignes pour corriger un certain comportement et reformater le fichier entier, je vais être très surpris lorsque j'ouvre le fichier. En tant que membres d'une équipe, nous ne devrions pas faire cela les uns aux autres. Si vous archivez ce fichier avec un reformatage complet et que vous ne m'informez même pas, ce n'est pas très convivial pour l'équipe.
cdkMoose
Dans la discussion originale des PO, j'ai lu que pour être un environnement sans normes de codage (ou pas bien appliqué), c'est pourquoi j'ai répondu comme tel. Dans cet environnement, un développeur ne devrait pas imposer ses normes aux autres.
cdkMoose