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?

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.

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.

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

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.

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

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.

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!

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.

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.

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.