Enregistrement du code « commenté »

Question

Ok, ici est quelque chose qui a causé des frictions, à mon travail et je n'avais vraiment pas prévu. Organisé dans la maison de développement de logiciels est un concept nouveau ici et j'ai élaboré une première ébauche de certaines règles de codage.

J'ai proposé que "commenté" code ne doit jamais être vérifié dans le référentiel. La raison je l'ai dit, c'est que le référentiel conserve un historique complet des fichiers. Si vous êtes en train de supprimer le code fonctionnel puis retirez-le complètement. Le référentiel garde vos changements de sorte qu'il est facile de voir ce qui a changé.

Cela a causé des frictions dans un autre développeur estime que le fait de prendre cette route est trop restrictive. Ce développeur voudrais être en mesure de commenter un peu de code qu'il est en train mais est incomplet. Ce code n'aurait jamais été enregistrés avant et puis non enregistré n'importe où. Nous allons utiliser TFS j'ai donc suggéré que les étagères les changements seront les plus la bonne solution. Il n'a pas été acceptée parce qu'il voudrait être en mesure de l'enregistrement des changements partiels qui peut ou ne peut pas être déployé.

Nous voulons, à terme, arriver à un point où nous sommes, en prenant avantage de l'Intégration Continue et de déployer automatiquement à un serveur web de développement. Actuellement, il n'existe pas de version de développement de serveurs web ou serveurs de base de données, mais qui vont toutes être changé rapidement.

De toute façon, quelles sont vos pensées? Croyez-vous que "commenté" le code est utile d'avoir dans le référentiel?

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

Edit: Pour plus de clarté, nous n'avons pas d'utiliser les branches. Si nous le faisions alors je dirais de faire ce que vous voulez avec votre private branch mais ne jamais fusionner commenté code avec le tronc ou d'un partage d'une des branches.

Edit: Il n'y a aucune raison valable de ne pas utiliser privée ou par utilisateur branches. Ce n'est pas un concept que j'en désaccord avec. Nous n'avons tout simplement pas de cette façon-là encore. Peut-être que c'est l'éventuel terrain d'entente. Pour l'instant nous utilisons TFS étagères.

Answer 1

Il peut y avoir d'autres personnes avec des expériences différentes, mais dans la mienne vérification en demi-finis code est une idée horrible, période.

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

• Vérifiez souvent - au moins une fois, mais de préférence plusieurs fois par jour
• Seulement vérifier dans la fonctionnalité complète
• Si le premier et le deuxième conflit (par exemple, il faut plus d'une journée pour que les fonctionnalités de travail), alors la tâche est trop grande diviser en plus petites tâches complétées.

Cela signifie:

• Commenté code ne doit jamais être vérifiée, car elle n'est pas fonctionnelle
• Commentaires n'est pas valide archives de la stratégie, de sorte que ce code n'est pas encore fini ou d'un code qui est à la retraite, de les commenter et de l'enregistrement n'a pas de sens.

Donc en résumé, PAS de! Si le code n'est pas prêt à passer à l'étape suivante (selon ce qui est pour vous: IntTest/AQ/UAT/PreProd/Prod), il ne doit pas être attachée à un tronc ou multi-développeur de la branche. Période.

Edit: Après avoir lu les autres réponses et commentaires, je vais ajouter que je ne pense pas que c'est nécessairement une bonne idée de l'interdiction d'un code commenté (je ne sais pas comment vous pouvez faire valoir ce que de toute façon). Ce que je vais dire, c'est que vous devriez avoir tout le monde dans votre équipe pour vous inscrire à la philosophie que j'ai décrit ci-dessus. L'équipe avec laquelle je travaille sur l'embrasse de tout mon cœur. En conséquence, la source de contrôle est un frictonless l'équipe-membre de, celui qui nous aide à nous faire notre travail.

Des gens qui n'embrassent que la philosophie est généralement la cause des fenêtres brisées et sont souvent frustrés par la source de contrôle. Ils le voient comme un mal nécessaire, au mieux, et quelque chose à éviter, au pire, ce qui conduit à de rares archivages, ce qui signifie que les révisions sont énormes et difficiles à fusionner, ce qui ajoute à la frustration, le fait archivages quelque chose pour éviter encore plus, etc. C'est finalement une attitude chose, pas vraiment un processus de chose. Il est facile à mettre en place les barrières mentales contre elle; il est facile de trouver des raisons pourquoi il ne fonctionne pas, tout comme il est facile de trouver des raisons de ne pas le régime alimentaire si vous ne voulez 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 pour les vendre de manière efficace.

Answer 2

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

Votre collègue a un excellent exemple de quand il pourrait être approprié de vérifier dans le code qui est commenté : quand il est incomplet et pourrait casser la demande s’il est activé tout en actif.

Pour la plupart, commentant dead code est inutile dans un système bien géré le changement. Mais, pas tous les commentaires de code est « morte ».

Answer 3

Commenté code doit jamais être vérifiée dans le but de maintenir l'histoire. C'est le point de contrôle de code source.

Les gens parlent beaucoup d'idéaux. Peut-être que contrairement à tout le monde, j'ai travailler sur de multiples projets avec de multiples interruptions avec le "monde réel" ocassionally interrompu ma journée de travail.

Parfois, la réalité est, j'ai le check-in partiellement code complet. C'est le risque de perdre le code ou de l'enregistrement du code incomplète. Je ne peux pas toujours se permettre de "terminer" une tâche, peu importe comment petit. Mais je vais pas débrancher mon ordinateur portable à partir du réseau sans vérifier-dans tous les code.

Si nécessaire, je vais créer ma propre branche de commettre des changements partiels.

Answer 4

Un seul cas où je laisse commenté le code :

quand c’est l’approche évidente au problème, mais il contient quelques défauts subtils. Bien sûr, le référentiel aurait-il mais le référentiel ne serait pas avertir tout le monde à l’avenir ne pas aller dans cette voie.

Answer 5

Je serais certainement décourager, fortement, toujours vérifier dans commenté code. Je ne voudrais pas, cependant, absolument interdire. Parfois (si rarement) il convient de vérifier commenté le code dans la source de contrôle. En disant "ne" est trop restrictive.

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

• Ne jamais vérifier code mort dans le contrôle de source
• Ne jamais vérifier cassé (non-fonctionnement) code de contrôle à la source, à moins de ne jamais , du tronc, et très rarement à une branche privé, YMMV
• Si vous avez temporairement commenté quelque chose ou cassé quelque chose à des fins de débogage, de ne pas vérifier le code jusqu'à ce que vous restaurez le code de sa forme correcte

Certains disent il y a d'autres catégories, telles que temporairement retiré de code, ou un différentiel, mais incomplète amélioration qui comprend une petite quantité de commenté de code que de la documentation de ce qui vient après, ou un très court (idéalement 1 ligne) extrait de a commenté le code de montrer quelque chose qui ne doit jamais être de nouveau ajoutés. Commenté code doit TOUJOURS être accompagné d'un commentaire qui explique pourquoi il est commenté (et pas seulement supprimé) et donne la durée de vie prévue de l'commenté code. Par exemple, "Le code suivant fait plus de mal que de bien, donc, est commenté, mais doit être remplacé avant la libération XXX."

Un commentaire comme ci-dessus est appropriée si vous délivrer un correctif pour arrêter un client de saignements et que vous n'avez pas la possibilité immédiate de trouver l'ultime correctif. Après la remise du correctif, le commentaire le code est un rappel que vous avez encore quelque chose à corriger.

Quand dois-je vérifier dans commenté code? Un exemple est lorsque je suis provisoirement retirer quelque chose que je pense qu'il y a une forte probabilité devra être ré-ajoutée dans un futur proche, dans une certaine forme. Le commentaire le code est là pour servir comme un rappel direct que c'est incomplet. Bien sûr, l'ancienne version est en contrôle de code source et vous pouvez simplement utiliser un FIXME commentaire comme un indicateur que quelque chose de plus est nécessaire. Cependant, parfois (souvent) du code est le meilleur commentaire.

Aussi, lorsqu'un bug est corrigé par la suppression d'une ligne (ou, plus rarement, deux lignes) du code, je vais parfois simplement en commentaire la ligne avec un commentaire à jamais ré-activer ce code avec une raison à cela. Ce genre de commentaire est clair, direct et concis.

Rex M a dit: 1) vérifier Uniquement dans la fonctionnalité complète, 2) [Si] la tâche est trop grande diviser en plus petites tâches complétées.

En réponse: Oui, c'est l'idéal. Parfois, aucune de ces options n'est possible que lorsque vous travaillez sur la production de code et à avoir, immédiatement, le problème essentiel à résoudre. Parfois, pour accomplir une tâche, vous avez besoin de mettre une version de code dans le champ pendant un certain temps. Cela est particulièrement vrai pour la collecte de données à des modifications de code lorsque vous essayez de trouver la cause racine du problème.

Pour le cas précis de posées à propos de la question plus générale ... tant que le développeur est en train de vérifier commenté de code dans une direction que personne ne va voir, mais que les développeurs (et peut-être quelqu'un le développeur est de collaborer avec d'), il ne peu de mal. Mais que développeur doit (presque) jamais de livrer le code dans le tronc ou un équivalent. Le tronc doit toujours construire et devrait toujours fonctionner. Livraison inachevé code de la route est presque toujours une très mauvaise idée. Si vous laissez un développeur de vérifier inachevé ou code temporaire dans une direction, alors vous devez compter sur les développeurs à ne pas oublier de frotter le code avant de livrer dans le tronc.

Pour préciser, en réponse à des commentaires à d'autres réponses, si le code est commenté et vérifié, je m'attends à ce que le code de la fonction si décommenté les gouttes avec la longueur de temps que le code a été commenté. Évidemment, le refactoring ne seront pas toujours d'inclure des commentaires dans leur refactoring. Presque toujours, si je mets commenté code en production, le code est là pour servir comme un cadre raffiné, commentaire, quelque chose de plus spécifique que la prose, que quelque chose doit être fait. Il n'est pas quelque chose qui devrait avoir une longue vie.

Enfin, si vous pouvez trouver commenté de code dans chaque fichier source, puis quelque chose est faux. La livraison a commenté le code dans le tronc pour toute raison devrait être un événement rare. Si cela se produit souvent, il devient l'encombrement et perd de sa valeur.