Enregistrement du code "commenté" [fermé]

Ok, voici quelque chose qui a causé des frictions dans mon travail actuel et je ne m'y attendais vraiment pas. Le développement de logiciels organisé en interne est un nouveau concept ici et j'ai rédigé un premier projet de quelques directives de codage.

J'ai proposé que le code "commenté" ne soit jamais archivé dans le référentiel. La raison pour laquelle j'ai déclaré cela est que le référentiel conserve un historique complet des fichiers. Si vous supprimez le code fonctionnel, supprimez-le complètement. Le référentiel conserve vos modifications afin qu'il soit facile de voir ce qui a été modifié.

Cela a causé des frictions dans la mesure où un autre développeur pense que cette voie est trop restrictive. Ce développeur aimerait pouvoir commenter un code sur lequel il travaille mais qui est incomplet. Ce code n'aurait alors jamais été archivé auparavant et ensuite enregistré nulle part. Nous allons utiliser TFS, alors j'ai suggéré que la mise en attente des modifications serait la solution la plus correcte. Elle n'a cependant pas été acceptée car il aimerait pouvoir enregistrer des modifications partielles qui peuvent ou non être déployées.

Nous voulons finalement arriver à un point où nous tirons pleinement parti de l'intégration continue et nous déployons automatiquement sur un serveur Web de développement. Actuellement, il n'y a pas de version de développement de serveurs Web ou de serveurs de bases de données, mais tout sera bientôt changé.

Quoi qu'il en soit, qu'en pensez-vous? Pensez-vous que le code «commenté» est utile dans le référentiel?

Je suis très intéressé d'entendre d'autres personnes sur ce sujet.

Edit: Par souci de clarté, nous n'utilisons pas de branches privées. Si nous le faisions, je dirais: faites ce que vous voulez avec votre branche privée, mais ne fusionnez jamais le code commenté avec le tronc ou les branches partagées.

Edit: Il n'y a aucune raison valable pour laquelle nous n'utilisons pas de branches privées ou par utilisateur. Ce n'est pas un concept avec lequel je ne suis pas d'accord. Nous ne l'avons tout simplement pas encore configuré de cette façon. C'est peut-être là le juste milieu. Pour l'instant, nous utilisons des rayonnages TFS.

Il peut y en avoir d'autres avec des expériences différentes, mais dans le mien, vérifier du code à moitié terminé est une idée horrible, point final.

Voici les principes que j'ai appris et que j'essaie de suivre:

• Enregistrez-vous souvent - au moins une fois, mais de préférence plusieurs fois par jour
• Archiver uniquement la fonctionnalité complète
• Si le premier et le deuxième conflit (par exemple, il faut plus d'un jour pour faire fonctionner la fonctionnalité), la tâche est trop grande - divisez-la en tâches plus petites pouvant être complétées.

Ça signifie:

• Le code commenté ne doit jamais être archivé car il n'est pas fonctionnel
• Les commentaires ne sont pas une stratégie d'archivage valide, donc qu'il s'agisse de code à terminer ou de code en cours de retrait, les commentaires et l'archivage n'ont aucun sens.

Donc en résumé, NON! Si le code n'est pas prêt à passer à l'étape suivante (selon celle qui vous convient: IntTest / QA / UAT / PreProd / Prod), il ne doit pas être validé dans une branche de tronc ou multi-développeur. Période.

Edit: Après avoir lu les autres réponses et commentaires, j'ajouterai que je ne pense pas que ce soit nécessairement une bonne idée d' interdire le code commenté (je ne sais pas comment vous le feriez de toute façon). Ce que je dirai, c'est que vous devriez amener tous les membres de votre équipe à adhérer à la philosophie que j'ai décrite ci-dessus. L'équipe avec laquelle je travaille l'adopte de tout cœur. En conséquence, le contrôle de code source est un membre de l'équipe sans frictions, qui nous aide à faire notre travail.

Les personnes qui n'adhèrent pas à cette philosophie provoquent généralement des fenêtres cassées et sont souvent frustrées par le contrôle de code source. Ils y voient au mieux un mal nécessaire, et quelque chose à éviter au pire; ce qui conduit à des vérifications peu fréquentes, ce qui signifie que les ensembles de modifications sont énormes et difficiles à fusionner, ce qui aggrave la frustration, fait des vérifications quelque chose à éviter encore plus, etc. C'est finalement une question d'attitude, pas vraiment de processus. Il est facile de dresser des barrières mentales contre cela; il est facile de trouver des raisons pour lesquelles cela ne fonctionnera pas, tout comme il est facile de trouver des raisons de ne pas suivre un régime si vous ne le souhaitez pas vraiment. Mais quand les gens ne veulent le faire et se sont engagés à changer leurs habitudes, les résultats sont spectaculaires. Le fardeau est sur vous de le vendre efficacement.

«Jamais» est rarement un bon mot à utiliser dans les lignes directrices.

Votre collègue a un excellent exemple de cas où il pourrait être approprié d'archiver du code qui est commenté: lorsqu'il est incomplet et peut interrompre l'application si elle est archivée lorsqu'elle est active.

Dans la plupart des cas, commenter le code mort n'est pas nécessaire dans un système contrôlé par le changement bien géré. Mais tout le code commenté n'est pas «mort».

Le code commenté ne doit jamais être archivé dans le but de conserver l'historique. C'est le point du contrôle de source.

Les gens parlent de beaucoup d'idéaux ici. Peut-être contrairement à tout le monde, je dois travailler sur plusieurs projets avec de multiples interruptions avec le «monde réel» occasionnellement interrompu ma journée de travail.

Parfois, la réalité est que je dois enregistrer un code partiellement complet. C'est soit un risque de perdre le code, soit un code incomplet. Je ne peux pas toujours me permettre de «terminer» une tâche, aussi petite soit-elle. Mais je ne déconnecterai pas mon ordinateur portable du réseau sans enregistrer tout le code.

Si nécessaire, je créerai ma propre branche de travail pour valider des modifications partielles.

Un cas où je laisse du code commenté:

// This approach doesn't work
// Blah, blah, blah

alors que c'est l'approche évidente du problème mais qu'elle contient un défaut subtil. Bien sûr, le référentiel l'aurait mais le référentiel ne préviendrait personne à l'avenir de ne pas s'engager dans cette voie.

Je découragerais certainement, fortement, de ne jamais vérifier le code commenté. Cependant, je ne l'interdirais absolument pas. Parfois (si rarement) il est approprié de vérifier le code commenté dans le contrôle de code source. Dire «ne jamais faire ça» est trop restrictif.

Je pense que nous sommes tous d'accord avec ces points:

• Ne vérifiez jamais le code mort dans le contrôle de code source
• Ne vérifiez jamais le code cassé (non fonctionnel) dans le contrôle de code source, du moins jamais dans le tronc et très rarement vers une branche privée, YMMV
• Si vous avez temporairement commenté quelque chose ou cassé quelque chose à des fins de débogage, ne archivez pas le code tant que vous n'avez pas restauré le code dans sa forme correcte

Certains disent qu'il existe d'autres catégories, telles que le code temporairement supprimé, ou une amélioration incrémentielle mais incomplète qui inclut une petite quantité de code commenté comme documentation de ce qui vient ensuite, ou un extrait très court (idéalement 1 ligne) de commentaire out code montrant quelque chose qui ne devrait jamais être rajouté. Le code commenté doit TOUJOURS être accompagné d'un commentaire expliquant pourquoi il est commenté (et pas simplement supprimé) et donne la durée de vie prévue du code commenté. Par exemple, «Le code suivant fait plus de mal que de bien, il est donc commenté, mais doit être remplacé avant la version XXX».

Un commentaire comme celui-ci est approprié si vous fournissez un correctif pour arrêter le saignement d'un client et que vous n'avez pas l'opportunité immédiate de trouver le correctif ultime. Après avoir fourni le correctif, le code commenté vous rappelle que vous avez encore quelque chose à corriger.

Quand dois-je enregistrer le code commenté? Par exemple, lorsque je retire provisoirement quelque chose qui, à mon avis, devra être rajouté dans un proche avenir, sous une forme ou une autre. Le code commenté est là pour vous rappeler directement qu'il est incomplet. Bien sûr, l'ancienne version est en contrôle de code source et vous pouvez simplement utiliser un commentaire FIXME comme indicateur indiquant que quelque chose de plus est nécessaire. Cependant, parfois (sinon souvent) le code est le meilleur commentaire.

De plus, lorsqu'un bogue est corrigé en supprimant une ligne (ou plus rarement deux lignes) de code, je vais parfois simplement commenter la ligne avec un commentaire pour ne jamais réactiver ce code avec une raison pour laquelle. Ce genre de commentaire est clair, direct et concis.

Rex M a dit: 1) Ne vérifiez que la fonctionnalité complète, 2) [Si] la tâche est trop grande - divisez-la en tâches plus petites pouvant être complétées.

En réponse: Oui, c'est l'idéal. Parfois, aucune des deux options n'est réalisable lorsque vous travaillez sur du code de production et que vous avez un problème critique immédiat à résoudre. Parfois, pour terminer une tâche, vous devez mettre une version de code sur le terrain pendant un certain temps. Cela est particulièrement vrai pour les modifications de code de collecte de données lorsque vous essayez de trouver la cause première d'un problème.

Pour l'instance spécifique évoquée dans la question plus générale ... tant que le développeur vérifie le code commenté dans une branche privée que personne ne verra à part ce développeur (et peut-être quelqu'un avec lequel le développeur collabore), cela fait peu de mal. Mais ce développeur ne devrait (presque) jamais livrer un tel code dans le coffre ou un équivalent. Le coffre doit toujours se construire et doit toujours fonctionner. Fournir du code inachevé au coffre est presque toujours une très mauvaise idée. Si vous laissez un développeur vérifier le code inachevé ou temporaire dans une branche privée, vous devez alors compter sur le développeur pour ne pas oublier de nettoyer le code avant de le livrer dans le coffre.

Pour clarifier en réponse aux commentaires d'autres réponses, si le code est commenté et archivé, je m'attends à ce que le code fonctionne s'il n'est pas commenté diminue avec la durée pendant laquelle le code a été commenté. De toute évidence, les outils de refactoring n'incluront pas toujours des commentaires dans leur refactoring. Presque toujours, si je mets du code commenté en production, le code est là pour servir de commentaire raffiné, quelque chose de plus spécifique que la prose, que quelque chose doit être fait là-bas. Ce n'est pas quelque chose qui devrait durer longtemps.

Enfin, si vous pouvez trouver du code commenté dans chaque fichier source, alors quelque chose ne va pas. La livraison de code commenté dans le coffre pour quelque raison que ce soit devrait être un événement rare. Si cela se produit souvent, cela devient du désordre et perd de sa valeur.

Je pense que jamais n'est une condition trop forte.

J'ai tendance à commenter, enregistrer, exécuter les tests, réfléchir puis supprimer les commentaires après la prochaine version.

En général, l'archivage du code commenté est erroné car cela crée de la confusion parmi ceux qui ne sont pas l'auteur d'origine et ont besoin de lire ou de modifier le code. Dans tous les cas, l'auteur original finit souvent par être confus au sujet du code après 3 mois.

Je suis convaincu que le code appartient à l'entreprise ou à l'équipe et qu'il est de votre responsabilité de faciliter les choses pour vos pairs. Archiver du code commenté sans ajouter également un commentaire expliquant pourquoi il est conservé revient à dire:

Cela ne me dérange pas si vous finissez par être confus sur la raison pour laquelle ce truc est ici. Mes besoins sont plus importants que les vôtres, c'est pourquoi je l'ai fait. Je ne ressens aucun besoin de vous justifier, ni à personne d'autre, pourquoi j'ai fait cela.

Pour moi, le code commenté est normalement considéré comme un signe de manque de respect de la part d'un collègue moins attentionné.

Je suis largement d'accord avec le principe selon lequel le code commenté ne doit pas être archivé. Le système de contrôle de source est une ressource partagée, et votre collègue l'utilise, dans une certaine mesure, comme son bloc-notes personnel. Ce n'est pas très attentionné pour les autres utilisateurs, surtout si vous souscrivez à l'idée de propriété partagée de la base de code.

Le prochain développeur à voir ce code commenté n'aurait aucune idée qu'il s'agit d'un travail en cours. Est-il libre de le changer? Est-ce du code mort? Il ne sait pas.

Si la modification de votre collègue n'est pas dans un état où elle peut être archivée, il doit la terminer et / ou apprendre à apporter des modifications plus petites et incrémentielles.

"Vérifier les changements partiels qui peuvent ou non être déployés" - cela signifie probablement aussi que l'on peut ou non être testé? C'est une pente glissante vers une base de code très difficile.

Lorsque vous avez besoin d'ajouter une petite fonctionnalité ou un correctif de bogue comme MAINTENANT, dans les 3 prochaines minutes et que vous devez réparer un fichier sur lequel vous avez du code à moitié développé, je dirais que c'est correct, les besoins pratiques prévalent sur les idéaux pragmatiques sur le champ de bataille.

Cela montre une différence fondamentale entre deux écoles de pensée: ceux qui ne vérifient que le code de travail dont ils sont satisfaits et qui estiment qu'il vaut la peine d'être sauvé, et ceux qui vérifient leur travail afin que le contrôle de révision soit là pour les soutenir contre la perte de données.

Je caractériserais ce dernier comme "ceux qui aiment utiliser leur système de contrôle de révision comme sauvegarde de bande de pauvre homme", mais ce serait me faire basculer la main quant au camp dans lequel je suis. :-)

Je suppose que vous êtes du camp du «bon code», et lui du camp du «code de travail».

[ÉDITER]

D'après les commentaires, oui, j'ai bien deviné.

Comme je l'ai dit, je suis avec vous, mais pour autant que je sache, c'est une opinion minoritaire, à la fois ici sur stackoverflow et là où je travaille. En tant que tel, je ne pense pas que vous puissiez vraiment l'inscrire dans vos normes de développement comme la seule façon de fonctionner. Pas si vous voulez que les normes soient respectées de toute façon. Une chose qu'un bon leader sait est de ne jamais donner un ordre dont il sait qu'il ne sera pas suivi.

btw: De bons éditeurs aideront à conserver les anciennes versions. Par exemple, dans Emacs, j'ai défini les anciennes versions conservées et les anciennes versions conservées sur 10, ce qui permet de conserver les 10 dernières sauvegardes de mes fichiers. Vous pourriez examiner cela comme un moyen d'aider votre argument contre la foule du contrôle de révision en tant que sauvegarde. Cependant, vous ne gagnerez jamais l'argument.

D'après mon expérience, les commutateurs de développeur sont du code commenté.

Parfois, de nouveaux back-ends sont construits en parallèle, les commutateurs d'activation étant commentés dans le contrôle de code source.

Une fonctionnalité bizarre dont nous avons besoin une fois sur une lune bleue mais dont aucun client n'aura jamais besoin est souvent mise en œuvre de cette façon. Ces éléments comportent généralement un risque élevé de contournement de la sécurité ou de l'intégrité des données, nous ne voulons donc pas qu'ils soient actifs en dehors du développement. Exiger d'un développeur qui l'utiliserait pour décommenter d'abord le code semble être le moyen le plus simple de l'obtenir.

Une autre raison pour le code commenté enregistré:

Vous modifiez du code existant et vous avez trouvé un bogue subtil, facile à ignorer, et qui pourrait même sembler correct à première vue. Commentez-le, mettez le correctif à sa place et ajoutez des commentaires sur ce qui se passe et pourquoi il a été modifié. Vérifiez-le, afin que vos commentaires sur le correctif soient dans le référentiel.

Peut-être que la vraie question ici est de savoir si les développeurs devraient être autorisés à enregistrer du code incomplet?

Cette pratique semble être en contradiction avec votre objectif déclaré de mettre en œuvre l'intégration continue.

Ça dépend. S'il est laissé là à des fins d'illustration, peut-être. Cela pourrait éventuellement être utile lors du refactoring. Sinon, et généralement, non. De plus, commenter du code inachevé est forcément à la fois sujet aux échecs et à une perte de temps. Mieux vaut qu'il brise le code en plus petits morceaux et les enregistre quand ils fonctionnent.

Mon point de vue: si les développeurs travaillent sur leurs propres branches, ou dans leur propre zone de bac à sable, ils devraient pouvoir enregistrer ce qu'ils veulent. C'est lorsqu'ils enregistrent du code dans une branche partagée (une branche de fonctionnalité, ou une branche d'équipe, ou bien sûr MAIN / trunk) que le code doit être aussi vierge que possible (pas de code commenté, plus de FIXME, etc.).

Je pense que "Jamais" est une règle trop forte. Je voterais pour laisser une marge de manœuvre personnelle pour savoir si les gens vérifient le code commenté dans le référentiel. Le but ultime devrait être la productivité du codeur, et non "un référentiel vierge".

Pour équilibrer ce laxisme, assurez-vous que tout le monde sait que le code commenté a une date d'expiration. Tout le monde est autorisé à supprimer le code commenté s'il existe depuis une semaine complète et qu'il n'a jamais été actif. (Remplacez "une semaine" par ce qui vous convient.) De cette façon, vous vous réservez le droit de tuer le désordre quand vous le voyez, sans interférer trop directement avec les styles personnels des gens.

Je suis tout à fait d'accord que le code commenté ne doit pas être archivé dans le référentiel, c'est à cela que sert le contrôle du code source.

D'après mon expérience, lorsqu'un programmeur enregistre du code commenté, c'est parce qu'il n'est pas sûr de la bonne solution et qu'il est plus heureux de laisser la solution alternative dans la source dans l'espoir que quelqu'un d'autre prendra cette décision.

Je trouve que cela complique le code et le rend difficile à lire.

Je n'ai aucun problème avec l'enregistrement du code à moitié fini (vous bénéficiez donc du contrôle de source) qui n'est pas appelé par le système en direct. Mon problème est de trouver des sections de code commenté sans explication, le dilemme était que le code était exclu.

Je pense que l'enregistrement du code commenté dans un système de contrôle de code source doit être effectué avec une extrême prudence, en particulier si les balises de langue utilisées pour commenter le code sont écrites par blocs, c'est-à-dire:

/* My commented code start here
My commented code line 1
My commented code line 2
*/

Plutôt que sur une base individuelle, comme:

// My commented code start here
// My commented code line 1
// My commented code line 2

(vous avez eu l'idée)

La raison pour laquelle j'utiliserais une extrême prudence est que, selon la technologie, vous devez faire très attention à l'outil de comparaison / fusion que vous utilisez. Avec certains systèmes de contrôle de code source et certains langages, l'outil de comparaison / fusion peut être facilement confondu. La diff / fusion standard de ClearCase par exemple est notoirement mauvaise pour la fusion de fichiers .xml.

S'il arrive que les lignes des blocs de commentaires ne se fusionnent pas correctement, votre code deviendra actif dans le système alors qu'il ne devrait pas l'être. Si le code est incomplet et casse la construction, c'est probablement le moins mal, car vous le repérerez immédiatement.

Mais si le code réussit la construction, il peut devenir actif alors qu'il ne devrait pas être là, et d'un point de vue CM, cela pourrait être un scénario de cauchemar. Le contrôle qualité teste généralement ce qui devrait être là, ils ne testent pas le code qui n'est pas censé y être, donc votre code peut finir en production avant que vous ne le sachiez, et au moment où il serait réalisé que le code est là quand il ne devrait pas, les coûts de maintenance ont multiplié de nombreux plis (comme le «bug» sera découvert en production ou par le client, pire endroit ou moment jamais).

L'idée de permettre à l'historique du contrôle de la source d'illustrer la «vieille façon» de faire quelque chose plutôt que de la commenter et d'enregistrer le commentaire avec une explication est une bonne idée en théorie.

Dans le monde réel, cependant, personne ne regarde jamais l'historique du contrôle de source sur les fichiers sur lesquels il travaille à moins que cela ne fasse partie d'un processus d'examen officiel (effectué uniquement périodiquement), ou si quelque chose ne fonctionne pas, et le développeur ne peut pas comprendre pourquoi.

Même dans ce cas, regarder plus de 3 versions en arrière ne se produit pratiquement jamais.

C'est en partie parce que les systèmes de contrôle de source ne facilitent pas ce genre de révision occasionnelle. Habituellement, vous devez vérifier une ancienne version ou une différence par rapport à une ancienne version, vous ne voyez que deux versions, et il n'y a pas de bonne vue concise de ce qui a changé qui peut vous donner une idée d'un coup d'œil de ce qui a changé.

C'est en partie la combinaison de la nature humaine et des besoins de l'équipe. Si je dois réparer quelque chose et que je peux le réparer en quelques heures, je ne passerai probablement pas une heure à enquêter sur les anciennes versions du code qui n’ont pas été "en ligne" depuis un mois (ce qui, chaque développeur vérifiant dans souvent, signifie revenir de nombreuses révisions), à moins que je sache qu'il y a quelque chose dedans (comme si je me souviens d'une discussion sur le changement de quelque chose lié à ce que je fais maintenant).

Si le code est supprimé et réintégré, alors, à toutes fins utiles (sauf dans le but limité d'une restauration complète), il cesse d'exister. Oui, il est là à des fins de sauvegarde, mais sans personne dans le rôle de bibliothécaire de code, il va se perdre.

Mon arbre de contrôle de source sur mon projet actuel a environ 10 semaines, sur une équipe d'environ 4 ingénieurs seulement, et il y a environ 200 listes de modifications validées. Je sais que mon équipe ne fait pas aussi bien son travail qu'elle le devrait de s'enregistrer dès qu'il y a quelque chose de solide et prêt à partir. Cela rend assez difficile de compter sur la lecture de l'historique du code pour chaque partie du code pour détecter chaque changement important.

En ce moment, je travaille sur un projet en mode développement initial, ce qui est très différent d'un projet en mode maintenance. Beaucoup des mêmes outils sont utilisés dans les deux environnements, mais les besoins diffèrent un peu. Par exemple, il y a souvent une tâche qui nécessite que deux ingénieurs ou plus travaillent en étroite collaboration pour créer quelque chose (par exemple, un client et un serveur).

Si j'écris le serveur, je pourrais rédiger le code de l'interface brouillon que le client utilisera et l'enregistrer complètement non fonctionnel, afin que l'ingénieur qui écrit le client puisse mettre à jour. C'est parce que nous avons la politique qui dit que la seule façon d'envoyer du code d'un ingénieur à un autre est via le système de contrôle de source.

Si la tâche prend suffisamment de temps, il vaudrait peut-être la peine de créer une branche sur laquelle nous travaillerons tous les deux (bien que cela soit contraire à la politique de mon organisation - les ingénieurs et les chefs d'équipe individuels n'ont pas les autorisations nécessaires sur le serveur de contrôle de source). En fin de compte, c'est un compromis, c'est pourquoi nous essayons de ne pas instituer trop de politiques «toujours» ou «jamais».

Je répondrais probablement à une telle politique de code sans commentaire en disant qu'elle était un peu naïve. Bien intentionné, peut-être, mais finalement peu susceptible d'atteindre son objectif.

Bien que voir cet article va faire revenir le code que j'ai vérifié la semaine dernière et supprimer la partie commentée qui n'était à la fois jamais définitive (bien que cela ait fonctionné) et qui ne sera probablement plus jamais souhaitée.

Je pense que le code commenté est considéré comme un «gaspillage».

Je suppose que vous travaillez dans un environnement d'équipe. Si vous travaillez seul et que vous commentez le code avec un «todo» et que vous y reviendrez, c'est différent. Mais dans un environnement d'équipe, vous pouvez supposer qu'une fois le code commenté archivé, il est là pour rester et cela causera probablement plus de douleur que de satisfaction.

Si vous effectuez des revues de code par les pairs, cela pourrait répondre à votre question. Si un autre développeur examine votre code et dit "pourquoi y a-t-il ce code commenté qui essaie de faire" bla "", votre code a échoué à la révision du code et vous ne devriez pas le vérifier de toute façon.

Le code commenté ne fera que soulever des questions avec d'autres développeurs - perdant ainsi du temps et de l'énergie.

Vous devez poser la question " pourquoi " le code est commenté. Quelques suggestions:

Si vous commentez du code parce que vous n'êtes "pas sûr des règles métier", vous avez probablement un problème avec le "fluage de la portée" - mieux vaut ne pas salir votre base de code avec des exigences qui "seraient bien, mais nous n'avons pas le temps à mettre en œuvre "- gardez-le propre avec un code clair et des tests autour de ce qui est réellement là.

Si vous commentez du code parce que vous n'êtes «pas sûr que ce soit la meilleure façon de le faire», faites examiner votre code par des pairs! Les temps changent, vous regarderez le code que vous écrivez aujourd'hui dans 2 ans et vous penserez que c'est horrible! Mais vous ne pouvez pas commenter des éléments dont vous «savez» qu'ils peuvent être améliorés, mais vous ne pouvez tout simplement pas trouver un moyen pour le moment. Que celui qui gère la base de code à long terme détermine s'il existe une meilleure façon - il suffit d'écrire, de tester et de travailler le code et de passer à autre chose.

Si vous commentez du code parce que "quelque chose ne fonctionne pas", corrigez-le ! Un scénario courant est celui des «tests cassés» ou des «choses à faire» . Si vous en avez, vous économiserez beaucoup de temps en les réparant ou simplement en vous en débarrassant. S'ils peuvent être «brisés» pendant un certain temps, ils peuvent très probablement être brisés pour toujours.

Tous ces scénarios potentiels (et ceux que je n'ai pas mentionnés ici) sont une perte de temps et d'efforts. Le code commenté peut sembler être un petit problème, mais pourrait être un indicateur d'un problème plus important dans votre équipe.

Les référentiels sont une sauvegarde du code. Si je travaille sur du code mais qu'il n'est pas terminé, pourquoi ne pas le commenter et l'enregistrer à la fin de la journée. De cette façon, si mon disque dur meurt du jour au lendemain, je n'aurai perdu aucun travail. Je peux vérifier le code le matin sans le commenter et continuer.

La seule raison pour laquelle je voudrais le commenter est que je ne voudrais pas casser la construction du jour au lendemain.

Il existe clairement une tension entre 1) l'enregistrement précoce et 2) le maintien en permanence du référentiel en état de fonctionnement. Si vous avez plus de quelques développeurs, ce dernier aura une priorité croissante, car vous ne pouvez pas avoir un développeur qui craque partout pour son propre flux de travail personnel. Cela dit , il ne faut pas sous-estimer la valeur de la première ligne directrice. Les développeurs utilisent tous les types de clôtures mentales, et les flux de travail individualisés sont un moyen pour les grands développeurs d'extraire ces X supplémentaires. En tant que manager, votre travail n'est pas d'essayer de comprendre toutes ces nuances - auxquelles vous échouerez à moins que vous ne soyez un génie et que tous vos développeurs soient des idiots - mais plutôt de permettre à vos développeurs d'être les meilleurs grâce à leur propre prise de décision.

Vous mentionnez dans le commentaire que vous n'utilisez pas de succursales privées. Ma question pour vous est pourquoi pas? D'accord, je ne sais rien de TFS, alors peut-être qu'il y a de bonnes raisons. Cependant après avoir utilisé git pendant un an, je dois dire qu'un bon DVCS diffuse totalement cette tension. Il y a des cas où je trouve utile de commenter du code pendant que je construis un remplacement, mais je perdrai le sommeil si je l'inflige à d'autres. Être capable de créer des branches localement signifie que je peux conserver des commits significatifs pour mon processus individuel sans avoir à me soucier (ou même à informer) les développeurs en aval des dégâts temporaires.

Je fais juste écho au refrain. Découragez cela à tout prix. Cela rend le code plus difficile à lire et laisse les gens se demander ce qui est bon / mauvais à propos de ce code qui ne fait même pas partie de l'application à l'heure actuelle. Vous pouvez toujours trouver des modifications en comparant les révisions. S'il y avait eu une intervention chirurgicale majeure et que le code était commenté en masse, le développeur aurait dû le noter dans les notes de révision sur l'archivage / la fusion.

le code incomplet / expérimental doit être dans une branche pour être développé jusqu'à la fin. la tête / le tronc doit être la ligne principale qui compile toujours et ce qui est expédié. une fois que la branche expérimentale est terminée, elle / acceptée, elle doit être fusionnée dans l'en-tête / la ligne principale. Il existe même une norme IEEE (IEEE 1042) décrivant cela si vous avez besoin d'une documentation d'assistance.

Je préférerais voir un code éventuellement cassé et accessible qui n'est pas encore utilisé sur le même code étant complètement indisponible. Étant donné que tous les logiciels de contrôle de version permettent une sorte de «copie de travail» distincte du coffre, c'est vraiment une bien meilleure idée d'utiliser ces fonctionnalités à la place.

Le nouveau code non fonctionnel est bien dans le coffre, car il est nouveau. Cela ne casse probablement rien de ce qui fonctionne déjà. Si cela casse le code de travail, alors il devrait simplement aller dans une branche, afin que les autres développeurs puissent (s'ils en ont besoin) vérifier cette branche et voir ce qui est cassé.

" Scar Tissue " est ce que j'appelle un code commenté. Dans les jours précédant l'utilisation généralisée des systèmes de contrôle de version, Code Monkeys laissait du code commenté dans le fichier au cas où ils auraient besoin de rétablir la fonctionnalité.

Le seul moment où il est acceptable d’enregistrer des «tissus cicatriciels» est

1. Si vous avez une succursale privée et
2. Vous n'avez pas le temps de faire la compilation du code sans erreurs et
3. Vous partez pour de longues vacances et
4. Vous ne faites pas confiance à votre VCS, comme si vous utilisez Visual Source Safe OU .
   [ÉDITER]
5. Vous avez un bug subtil qui pourrait être réintroduit si le code incorrect n'est pas laissé en guise de rappel. (bon point d'autres réponses).

Il n'y a presque aucune excuse pour # 4 car il existe de nombreux systèmes VCS robustes et librement disponibles, Git étant le meilleur exemple .

Sinon, laissez simplement le VCS être votre distributeur d'archives et de code. Si un autre développeur souhaite consulter votre code, envoyez-lui les différences par e-mail et laissez-le appliquer directement les éléments qu'il souhaite. Dans tous les cas, la fusion ne se soucie pas de savoir pourquoi ou comment le codage de deux fichiers a divergé.

Parce que c'est du code, le tissu cicatriciel peut être plus distrayant même qu'un commentaire bien écrit. De par sa nature même de code, vous obligez le programmeur de maintenance à dépenser des cycles de processeur mentaux pour déterminer si le tissu cicatriciel a quelque chose à voir avec ses changements. Peu importe que la cicatrice ait une semaine ou 10 ans, laisser le tissu cicatriciel dans le code impose un fardeau à ceux qui doivent déchiffrer le code après les mots.

[EDIT] J'ajouterais qu'il y a deux scénarios majeurs qui doivent être distingués:

• développement privé, soit en codant un projet personnel, soit en s'enregistrant dans une succursale privée
• Développement de maintenance, où le code en cours d'enregistrement est destiné à être mis en production.

Dites simplement "NON" au tissu cicatriciel!

Je ne sais pas - je commente toujours les lignes originales avant d'apporter des modifications - cela m'aide à les revenir si je change d'avis. Et oui, je les enregistre.

Cependant, je supprime tout ancien code commenté de l'enregistrement précédent.

Je sais que je pourrais consulter les journaux de différences pour voir ce qui a changé, mais c'est pénible - c'est bien de voir les derniers changements juste là dans le code.

Un bon compromis est d'écrire un petit outil qui vide vos fichiers extraits / modifiés sur un lecteur de sauvegarde réseau. De cette façon, vous pouvez modifier le contenu de votre cœur et sauvegarder votre travail, mais vous n'avez jamais à enregistrer du code expérimental ou inachevé.

Je pense que l'enregistrement du code commenté devrait être valide car, simplement parce que le nouveau changement a réussi les tests, il peut être plus utile de voir ce qui existait auparavant et de voir si le nouveau changement est vraiment une amélioration.

Si je dois revenir en arrière sur plusieurs versions pour voir un changement antérieur qui conduit maintenant à une baisse des performances, ce serait très ennuyeux.

Parfois, le code commenté est un bon historique, mais indiquez les dates auxquelles le code a été commenté. Plus tard, quelqu'un qui travaille près de là peut simplement supprimer le code commenté car il a été prouvé qu'il n'était pas nécessaire.

Il serait également bon de savoir qui a commenté ce code afin que, si une justification est nécessaire, on puisse leur demander.

Je préfère écrire de nouvelles fonctionnalités, m'assurer que les tests unitaires réussissent, les archiver, puis permettre aux autres de les utiliser et de voir comment cela fonctionne.

Si le développeur a commenté du code parce qu'il n'est pas encore terminé, la bonne façon de gérer ce problème serait que ce développeur le conserve dans une branche distincte, jusqu'à ce que ce code soit prêt à vérifier dans.

Avec un DVCS (comme git, bazaar ou mercurial), c'est très facile car cela ne nécessite aucun changement dans le référentiel central. Sinon, vous pourriez peut-être parler de donner aux développeurs leurs propres branches sur le serveur s'ils travaillent sur des fonctionnalités spécifiques qui leur prendront suffisamment de temps (c'est-à-dire des jours).

Il n'y a rien de mal à enregistrer du code commenté dans certaines situations, c'est juste qu'il s'agit d'une situation où il peut y avoir une meilleure façon de le faire, afin que le développeur puisse suivre les modifications apportées à sa source même s'il n'est pas prêt à l'être archivé dans le référentiel principal.

De toute évidence, le développeur qui enregistre le code commenté doit travailler dans une branche distincte, en fusionnant les modifications de la branche du tronc si nécessaire.

Il appartient au système VCS d'aider le développeur dans ce flux de travail (git est un excellent système VCS qui fonctionne très bien avec cela).