Validation lors du changement de formatage de la source?

Question

Est-il accepté de s'engager même lorsque vous changez simplement des choses comme des espaces, le formatage de code, etc.?

Answer 1

Oui. Si vous avez besoin d'effectuer des modifications d'espaces, les faire dans un commit séparé qui contient uniquement ce type de nettoyage est la meilleure pratique. Cela évite les problèmes d'essayer de voir quelle partie d'un diff géant est un changement de code réel, et quelle partie est juste le formatage (cosmétique) des changements.

Cela dit, vous devriez essayer de garder ce genre de changements au minimum, et seulement le faire du tout quand il est nécessaire et compatible avec ce que les normes de codage sont utilisées dans votre entreprise/communauté/projet/etc

Answer 2

Oui, à condition qu'il y ait une certaine cohérence entre les différents référentiels impliqués, sinon cela rendrait toute fusion beaucoup plus difficile à faire, à cause du conflit dû au formatage.
Au moins un commit séparé permet d'identifier la véritable source de conflit potentiel lors de ces futures fusions. Si ce n'est pas votre code (c'est-à-dire que d'autres repo avec d'autres standards de formatage doivent fusionner ce que vous faites), vous pouvez profiter du git attribute filter driver et de son mécanisme de nettoyage/nettoyage.

^{(Source: Pro Git book: Customizing Git - Git Attributes)}

Vous pouvez appliquer votre format au code lors de l'étape de bavure et réappliquer le format standard commun lors de l'étape propre.

Answer 3

Oui! Oui! En tant que commit séparé, s'il vous plaît! (Ces types de modifications ont tendance à toucher beaucoup de code, et les gens ont besoin de savoir si un commit/changeset/patch/what est là pour des raisons de reformatage, sans aucune modification du code.)

Answer 4

G 'jour,

Oui. Mais s'il vous plaît le faire comme dédié à commettre un message indiquant que vous avez

• mise en forme a changé,
• exécuter le code par un formateur de code, par exemple Perltidy, avec une note sur le réglage effectivement utilisé,
• etc.

Rien de pire que d'avoir la mise en forme des changements combinés avec des mises à jour fonctionnelles faisant une diff entre les versions fournit un mauvais rapport S/N! En passant, je me demande pourquoi vous faites des changements à la mise en forme du code existant. Il n'aurait pas dû être vérifié s'il était mal formaté en premier lieu!

Il n'y a rien de pire que de travailler avec quelqu'un qui passe par le changement source bien formaté pour aucune autre raison autre que: de la déclaration « si »

• ils pensent accolades appartiennent à la ligne, ou
• ils n'aiment pas "chouchouté elses", ou
• etc.
• etc.

Ces expressions religieuses de " le seul vrai style "généralement contredire un manque d'expérience de codage et d'expérience dans le travail en équipe.

HTH

acclamations,

Answer 5

Les réponses déjà ici font un bon travail d'expliquer pourquoi il peut être un problème pour commettre des changements de formatage. Je pense qu'une solution serait le support de l'éditeur pour permettre de voir du code bien formaté tout en minimisant les changements de formatage lors de la sauvegarde du fichier.

J'ai posé une question connexe à ce sujet dans ...

• Is there a text editor that will "pretty print" for display without changing the underlying text?

Si les bonnes réponses sont là, les téléspectateurs de cette question peut également être intéressé.