Vaut-il la peine de s’engager uniquement à résoudre des fautes de frappe non critiques?

67

Si je rencontre une faute de frappe non critique dans le code (par exemple une apostrophe erronée dans une instruction print (error)), est-il utile de s’engager à résoudre cette erreur ou faut-il simplement la laisser seule?

En particulier, je suis curieux de savoir comment comparer le gommage du journal de validation à la résolution de ces erreurs de frappe non critiques. Je penche pour les résoudre. Suis-je pédant?

version-control grammar Christopher Berman
la source
40
Si un commit trivial ne gomme rien, vous devez soit investir dans un meilleur VCS, de meilleurs outils de filtrage des journaux, ou de meilleures pratiques pour la consignation de différentes sévérités de correctif.
Rex Kerr
@ root45 Bien que, si vous regardez les résultats, ils constituent tous un type de grammaire différent de celui que cette question pose.
Izkata

Réponses:

130

Mon sentiment personnel est que l'amélioration de la qualité vaut le désagrément mineur d'une entrée supplémentaire dans le journal de validation, même pour de petites améliorations. Après tout, les petites améliorations comptent beaucoup lorsque vous tenez compte de l' effet de fenêtre brisé .

Vous voudrez peut-être le préfixer avec une TRIVIAL:balise ou le marquer comme trivial si votre VCS le prend en charge.

thiton
la source
72
Ce que je veux juste ajouter, c'est que je préférerais que des choses comme celle-ci soient commises séparément que combinées avec autre chose. Le problème avec le regroupement est qu'un excès de bruit peut distraire un relecteur de code des modifications correspondantes. +1
Andy
9
+1 pour mentionner l'effet de fenêtre cassé. Les petites choses comptent. Si tout est vraiment propre, les gens vont réfléchir à deux fois avant de commettre un code écrit négligemment ou non testé.
Roy Tinker
25
De même, si vous l'associez à une fonctionnalité, vous devez redéfinir la fonctionnalité que vous perdez. Commettez une chose à la fois.
ctrl-alt-delor
4
Je serais très intéressé de savoir quels VCS permettent de marquer les commentaires comme étant triviaux. J'ai travaillé avec SVN, Hg et Git et je n'ai rien remarqué de tel dans ces deux cas.
Xion
3
@Andy, ce bruit n'est pas la pire partie ... si, par la suite, quelqu'un décide de revenir par exemple sur ce commit parce qu'il ne veut pas cette fonctionnalité, vous perdez soudainement une petite amélioration qui faisait partie du (des) commit (s).
rFactor
49

Vous n'êtes pas pédant, et il est préférable de les résoudre individuellement. Plus un changement est atomique, mieux c'est - vous ne voulez pas qu'un correctif de bogue bloquant soit mélangé à 500 modifications de commentaire / typo.

jmoreno
la source
9
+1 Chaque révision ne doit concerner qu'un seul correctif spécifique. Cela devient un cauchemar pour annoncer des correctifs si chaque révision a aussi un tas de fautes de frappe aléatoires fixées entre les changements réels.
Grant
28

Dans le cas général: oui

Cela vaut toujours la peine d'augmenter la maintenabilité de votre logiciel.

Allez juste pour ça.

Si vous êtes sur le point d'expédier une version ...

... et si vous n'êtes pas le chef d'équipe, alors vérifiez avec lui .

En ce qui concerne le contenu du journal de validation ...

Je suis d’accord avec les autres pour dire que vous devriez au moins écrire quelque chose qui le distingue des commits liés aux "fonctionnalités", s’il ne s’agit que de corriger une faute de frappe isolée.

Une pratique courante consiste à avoir des tâches qui ne meurent jamais dans votre outil de suivi des problèmes pour suivre les changements intemporels et sans fin. Par exemple, il n’est pas rare d’avoir une tâche pour:

  • grands nettoyages automatisés inoffensifs (espaces blancs balayés),
  • chasse à la grammaire et au typo,
  • construire des modifications du système,
  • etc...

Veillez simplement à ce que ceux-ci ne soient pas utilisés comme identifiants de tâches à jeter pour à peu près n'importe quoi, lorsque les gens deviennent paresseux pour créer des tickets correctement documentés. Surtout si vous refusez les commits qui ne sont pas liés à un identifiant (ce qui est une bonne chose, mais de telles tâches volumineuses seront encore plus attrayantes pour les développeurs paresseux).

haylem
la source
7
Vérifier auprès de votre chef d'équipe pour une solution de frappe? Si j'étais le chef d'équipe stressé par la publication à venir, je ne voudrais pas être dérangé par de telles trivialités.
Joh
2
@Joh: ce n'est pas que vous pourriez forcément interrompre la construction, mais il pourrait y avoir d'autres tâches de construction, ou bien l'une d'elles pourrait déjà être étiquetée et prête à être utilisée, et vos contrôles d'audit (selon votre secteur d'activité) pourraient vous forcer à lier ce commit inoffensif. aux tâches et aux exigences, donc si cela vient de nulle part, cela peut être un peu un casse-tête; que vous pourriez facilement économiser quelques jours seulement après la sortie de la sortie. Mais en général, je suis d’accord avec vous et je dirais même qu’une entreprise fonctionnant de cette façon fait mal les choses. Mais ce n'est pas vous qui allez régler ce problème, alors faites-le savoir si vous n'êtes pas senior.
Hayem
2
@Joh: En gros, si mon chef d'équipe voit une nouvelle version sauter soudainement sur le système de construction lorsqu'il est sur le point de commencer une nouvelle version (ou l'a déjà démarrée), je peux vous assurer que son niveau de stress sera plus élevé en utilisant cette approche. ainsi ...
haylem
7

Les fautes de frappe doivent être ajoutées en tant que commit. Corriger les mots mal orthographiés ou les erreurs grammaticales augmentera la lisibilité de votre code.

L'utilisation d'un message de validation tel que "Correction typo" ou "Correction typo dans fichier.c" vous aidera à distinguer ces validations des autres validations de code majeures.

Trevor
la source
7

Oui, vous devriez absolument le faire, particulièrement tôt dans un projet.

Pourquoi? Deux points:

  1. Vous ne saurez probablement pas si une faute de frappe est "critique" ou pas avant qu'il ne soit trop tard. Certaines corrections ne sont probablement pas corrigées car tout le monde pense que ce ne sera pas grave. Jusqu'à ce que ce soit.

  2. Corriger une faute de frappe tôt et délibérément sera beaucoup plus facile que de la corriger après plusieurs centaines de lignes d'appels de code / fonctions. Encore une fois, les piratages temporaires peuvent devenir semi-permanents étonnamment rapidement. C'est pourquoi je dois traiter avec des objets ayant à la fois les méthodes "CollapseAll" ET "ColapseAll".

joshin4colours
la source
2
Oui. De toutes les bonnes réponses, j'aime bien celle-ci car elle dépend du "quand".
Wonko the Sane
4

Pour les erreurs grammaticales pouvant être détectées par un utilisateur final, alors oui, il va sans dire que cela vaut la peine de procéder à la validation, car il est tout à fait possible qu'un utilisateur ou un responsable de l'assurance qualité vienne signaler l'erreur et qu'il soit nécessaire de la suivre. Si le problème est déjà résolu, cela pourrait accélérer le processus de résolution du problème.

S'il s'agit d'une erreur grammaticale dans les commentaires autour du code, je ne ferais rien à ce sujet sauf si cela fait partie des modifications apportées au code lui-même, auquel cas vous mettez à jour la documentation du code.

rjzii
la source
3

Si vous craignez de graver le journal de validation, vous faites autre chose de mal. :-) Les commits fréquents sont une bonne chose! Je commets des corrections de frappe tout le temps. Obtenez-les dans la base de code dès que possible et accélérez le cycle de développement!

Brian Knoblauch
la source
2
I commit typo fixes all the timeOMI c'est inquiétant, essayez de trouver des programmeurs avec un meilleur anglais?
Lie Ryan
Vous prenez ce que vous pouvez obtenir ces jours-ci. Trouver des programmeurs capables d’écrire du code exploitable est un problème sérieux!
Brian Knoblauch
2

Je vote oui. Je les ai vérifiées. J'ai travaillé pour une entreprise qui détestait faire vérifier les choses. Je veux dire presque tout. Les critiques de code étaient exhaustives et donc, si vous avez enregistré une modification qui corrigeait une faute de frappe, vous vous êtes plaint. Vous pouvez imaginer l'état du code. En réalité, le code n'était pas terrible, mais il coulait comme une mélasse plutôt que de couler comme du vin.

Ian
la source
0

Votre processus de gestion du changement le permet-il?

Dans mon environnement, chaque validation que je fais doit être liée à une demande de modification qui a été demandée par les utilisateurs professionnels ou par une modification obligatoire au niveau du système, ainsi que les processus de test de l'utilisateur final correspondants. Une simple faute de frappe, comme celle que vous décrivez, ne serait probablement pas consignée comme l'une de celles-ci (j'ai trouvé des fautes de frappe et des erreurs grammaticales dans l'une de mes applications qui existait depuis plus de 4 ans sans que personne ne s'en aperçoive), donc si / quand les auditeurs sont venus appeler j'aurais beaucoup de mal à m'expliquer.

Je voudrais enregistrer un changement tel que vous le décrivez (et en avoir un, en fait - un nom de méthode est mal orthographié et je viens de le découvrir) pour un moment où j'ai un "vrai" changement qui doit être fait aussi bien et mettre "corrigé diverses fautes de frappe" dans le journal.

alroc
la source
+1 Dans certains environnements, cela est vrai. S'il vous plaît, ne votez pas parce que ce n'est pas vrai là où vous travaillez.
MarkJ
-1 votre processus de gestion du changement semble perdre beaucoup de temps . Je comprendrais (et même préférerais ) que chaque commit doit être lié à une demande de changement - cette partie de votre processus a l’air bien. Mais OMG, il semble que les requêtes initiées par les développeurs (comme les refactors ceci / corrections de fautes de frappe en cela ) soient interdites, ce qui m’amène un gros drapeau rouge . Cela suppose en quelque sorte que les utilisateurs professionnels / auditeurs en savent toujours mieux que les développeurs - si cela se rapprochait de la vérité, ils écriraient eux
bonjour
Si le développeur parvient à convaincre les personnes qui approuvent les modifications qu’il vaut la peine d’apporter d’approuver, il peut aller de l’avant. Mais si je trouve une simple faute de frappe dans le nom d'une méthode, ou du code copié / collé qui doit être refactorisé dans une méthode, je ne peux pas effectuer la modification sans autorisation. Il ne s'agit pas simplement de "faire ce qu'il faut avec le code" - des tests d'acceptation doivent être effectués, et les développeurs ne sont pas en position de pouvoir dire aux gens d'affaires "J'ai fait ce changement, vous ne remarquerez jamais ce que je a fait, mais vous devez passer par un cycle de test ".
alroc
@alroc que "si-peut-convaincre" cache simplement un processus contre-productif sous une surface d'aspect raisonnable. Il est judicieux de convaincre les entreprises / auditeurs d’importants changements, de points de contrôle jalons convenus, etc., etc. Passer quelques heures / jours à justifier un effort qui prend une semaine de développement et d’assurance qualité, c’est fastidieux mais juste, OK. Mais forcer cela pour chaque méthode d' orthographe ou d' extrait ... donnez-moi une pause - il ne s'agit que d'un contrôle insensé inséré au mauvais moment et au mauvais moment
gnat
Laissez-moi essayer d'expliquer cela à nouveau. Si je peux corriger une faute de frappe ou extraire une méthode tout en travaillant sur une autre modification approuvée, je peux la glisser sans avoir à en vendre à qui que ce soit. Mais je ne peux pas faire un changement qui ne soit pas visible par l'utilisateur et qui n'ait pas un impact positif direct sur l'entreprise / les utilisateurs sans vendre les pouvoirs qui en découlent.
Alroc
-1

Utiliser DVCS pour éditer l'historique

Si vous êtes préoccupé par un historique de validation vierge, envisagez d'effectuer votre travail principal dans les branches de fonctionnalités . Si vous travaillez avec un VCS distribué , vous pouvez facilement modifier votre historique de validation avant de le transférer dans la branche principale. Si vous êtes sur SVN, essayez Git - il peut interagir de manière bidirectionnelle avec Subversion et vous pouvez également modifier l'historique avant de vous engager réellement dans Subversion.

Gardez le bon sens autrement

Si vous ne souhaitez pas ou ne pouvez pas modifier l'historique des validations, il n'y a aucune raison fonctionnelle d'effectuer une validation précoce ou atomique pour une faute de frappe mineure n'affectant ni les tests automatiques ni la compilation . Dans ce cas, à mon avis, garder l’historique des commettations propre devrait être plus important que de faire des commits vraiment atomiques. Le fait de mélanger une ou deux corrections typo avec une modification "régulière" ne nuira à aucun processus de révision potentiel. Vous pouvez toutefois vouloir regrouper plusieurs corrections triviales dans un commit, par exemple lors du "nettoyage" après une session de codage plus importante.

Notez que les bogues fonctionnels doivent toujours être validés dès que possible dans un commit atomique.

Le ton général des réponses semble suggérer une stratégie consistant à "tout mettre en œuvre rapidement", même pour les fautes de frappe mineures. J'ai tendance à être en désaccord et à bien accueillir la discussion.

krlmlr
la source