Ancien code dans les commentaires [fermé]

Question

Combien de temps devez-vous conserver l'ancien code commenté dans votre base de code? Les sous-traitants continuent de conserver l'ancien code dans la base de code en le transformant en commentaires. C'est vraiment frustrant et je veux qu'ils suppriment simplement l'ancien code au lieu de le commenter.

Existe-t-il une raison valable de conserver l'ancien code dans la base de code sous forme de commentaires? J'utilise le contrôle de version de Visual Sourcesafe

Answer 1

Si vous utilisez quelque chose comme SVN ou CVS, non. Je les effacerais à vue. Ils rendent le code moins lisible.

Les commentaires doivent être là pour aider le programmeur qui lit le code, explique des choses, etc.

Answer 2

Une raison valable à laquelle je peux penser est cet exemple (fictif):

# removed the following test because this should work now that bug #12345 is fixed.
#assert a != 0
b = number / a

En gros, pour empêcher les autres développeurs de réinsérer le code qui a été supprimé pour une raison.

Answer 3

Dites aux entrepreneurs de cesser de le faire. C'est une pratique terrible.

Il n'y a pas vraiment de raison de conserver l'ancien code dans la base de code; ça gêne juste. Votre système de contrôle de version vous montrera l'historique de chaque fichier.

La seule raison possible de conserver l’ancien code, c’est peut-être pour référence historique (peut-être si l’ancien code faisait quelque chose de particulièrement étrange et qui pourrait être pertinent pour la situation actuelle).

Parfois, je commenterai le code en sachant que je mets un changement temporaire (par temporaire, je veux dire moins de quelques jours) et je compte bien y revenir.

modifier: une autre pratique connexe consiste à mettre les noms et les dates des modifications dans le fichier:

// 06/20/2009 - joe changed this #1245

Ne faites pas ça non plus. Cela peut sembler utile à l’époque de voir qui a fait un changement, mais avec le temps, cela n’a vraiment aucune valeur et encombre le code.

Answer 4

Si vous utilisez le contrôle de source que vous devriez utiliser, supprimez l'ancien code, car une copie sera prête pour le contrôle de code et vous attendra si vous avez besoin de le rajouter. Avoir l'ancien code dedans réduira la capacité de lire le code comme indiqué ci-dessus et introduira de la confusion. De plus, si vous faites appel à des entrepreneurs pour rédiger votre code, dites-leur comment coder pendant que vous payez leur salaire. Définissez des normes de codage pour eux et incitez-les à coder par intention, ce qui devrait améliorer le nom des méthodes, propriétés, etc. et réduire le nombre de commentaires.

Answer 5

Vous demandez "combien de temps?" Je ne suis pas offensé d’avoir l’ancien code à un ou deux endroits, si ce sont les points chauds où les gens travaillent encore.

Peut-être qu’ils n’ont pas encore confiance en ce nouveau code. Le nouveau code est-il "terminé?" Est-il écrit comme il se doit? Est-ce que ça passe des tests? Est-ce commenté et documenté à la spécification? La performance est-elle telle qu'elle devrait être? (La meilleure raison pour laquelle je peux penser à avoir l'ancien code et le nouveau code à la fois, c'est lorsque je chronomètre ou que je profile un certain nombre de cas.)

Y a-t-il quelque chose à propos de l'ancien code qui soit préférable au nouveau code?

Les entrepreneurs se sentent-ils pressés? Ou est-ce juste une vieille habitude des jours de contrôle avant la version?

Answer 6

Lorsque vous rappelez aux sous-traitants qu'ils ne doivent pas commenter le code, SourceSafe gardera l'historique pour leur demander pourquoi ils le font.

Il se peut qu’ils ne lui fassent pas confiance pour une raison quelconque. Si vous pouvez obtenir cette raison hors d'eux, ils pourraient faire attention. Je sais que lorsque nous avons quitté VSS il y a de nombreuses années, c'était peut-être à cause de problèmes de fiabilité et d'évolutivité. Si vous pouvez répondre à leurs préoccupations, soit en démontrant que VSS répond à vos besoins, soit en vous demandant d'enquêter sur d'autres solutions de contrôle de source (si vous avez le budget pour le faire, bien sûr), vous devriez les convaincre.

La persuasion vaut mieux que la contrainte.

Answer 7

Oui, détruisez-le à vue. Cela ne donne aucune valeur autre que celle de montrer que le développeur qui l'a commenté n'était pas sûr de le supprimer. Ou bien ils ne savent pas comment utiliser votre logiciel de contrôle de source.

Answer 8

En gros, vous n’avez que 2 options.

1. Supprimez-le lorsque vous utilisez un référentiel de code. Votre référentiel vous indiquera précisément quelles modifications ont été apportées. Il n'est donc pas nécessaire de conserver de longs commentaires anciens dans votre code de travail, ce qui n'explique rien en langage simple.
2. D’un autre côté, si vous souhaitez conserver ce code pour plusieurs raisons, par exemple, j’ai commenté un code de calcul en virgule flottante dans mon application, car il ne fonctionnait pas sur la plate-forme pour laquelle je programmais. Mais comme je ne voudrais pas que mon application reste limitée à cette plate-forme, j'ai gardé le code là-bas. Cela évite donc des efforts lorsque je porte l'application sur une plate-forme qui prend en charge les calculs en virgule flottante. Ce n'est qu'une des raisons pour conserver l'ancien code et pourrait s'appliquer aux personnes du même contexte.

Sinon, vos 2 seuls choix sont mentionnés ci-dessus. Votre appel !!

Answer 9

En gardant l'ancien code, il est plus difficile de lire le code dans son ensemble. Tant qu'il existe une forme de contrôle de version pour le projet, le code mis en commentaire doit être supprimé. Si vous ne possédez pas de contrôle de révision et que vous ne pouvez pas en configurer, il est conseillé de placer l'ancien code dans un fichier ne faisant pas partie de la base de code.

Answer 10

Je suppose que vous faites référence à des blocs de code significatifs qui semblent avoir une certaine valeur, ou à de bons algorithmes à part entière, pas seulement la ligne impaire ici ou là.

Dans ces cas, il y a une tendance naturelle à conserver le code. Si vous avez apporté des modifications importantes, le fait de conserver l’ancien en tant que commentaires constitue une forme de révision du code. Toute personne disposant de la dernière version sera en mesure de voir instantanément les modifications importantes qui ont été apportées et, en cas de problème, de voir beaucoup plus facilement ce qui existait auparavant. Si le problème vient du nouveau code, il existe un moyen très simple de le vérifier instantanément.

Donc, étant donné que j’ai tendance à commenter l’ancien code lors de la première révision, puis à ne le supprimer que lorsque le code a été modifié de nouveau, le changement sera désormais "intégré" et ne sera probablement pas une cause de bugs.

Ces commentaires sont une forme de documentation, il n’est pas nécessaire de les supprimer pour un idéal puriste de codage «propre». Supprimez-les lorsqu'ils ne sont plus nécessaires, conservez-les pendant qu'ils sont utiles.

Answer 11

Tout d'abord, je vous dis de vous en débarrasser.

Mais je connais une raison de ne pas le faire: même si cela se trouve toujours dans votre contrôle de version, cela ne signifie pas que tout le monde peut le voir. Si vous avez besoin de le revoir, vous devez d'abord savoir qu'il a déjà existé. Parfois, vous apportez une modification qui oblige les futurs développeurs à voir à la fois l'ancienne et la nouvelle manière. Si vous supprimez l'ancienne, comment les développeurs savent-ils que c'était déjà arrivé? La plupart des gens ne documentent pas assez les modifications apportées au contrôle de version pour résoudre ce type de problème.

Answer 12

Autant de raisons de laisser l’ancien code là-bas. Fondamentalement - une fois supprimé, il disparaîtra - à moins que quelqu'un se souvienne réellement de son existence.

En tant qu'entrepreneur diabolique, je ne supprime pas le code sauf si je suis en train de réécrire une procédure en profondeur - de le supprimer et de le remplacer plutôt que de "réparer". il.

Answer 13

Le projet que je présente actuellement utilise encore une autre approche - une sorte de compromis ... Lorsque vous décidez qu’une partie du code ne doit plus être utilisée, il vous suffit de la commenter, d’écrire la date en commentant et (si cela est possible - par exemple dans Netbeans ou VisualStudio), vous insérez l'ancien code dans #region OLD_IMPL. Effet? - Vous avez encore un ancien code au cas où - Le bloc de code non utilisé prend exactement 1 ligne (#region OLD_IMPL) - Si vous voyez que ce code n'est pas utilisé pendant un an (vous avez la date pour le commenter), vous pouvez simplement le supprimer.

En cas de situations critiques, vous utilisez toujours SVN;)

Answer 14

Ceux qui disent se débarrasser du code hors commentaire, car les outils de contrôle de version résoudront tous les problèmes que vous pourriez rencontrer, sont des idiots.

Vous devez vous débarrasser du code obsolète, UNE FOIS QUE VOUS ÊTES POSITIVEMENT SÛR QU'IL SOIT VRAIMENT VÉRITABLEMENT.

N'a jamais eu à réviser une modification car "ce n'était pas tout à fait mauvais, mais hélas ce n'était pas tout à fait bien non plus". ? Si vous pouvez toujours supprimer le source de production et savoir que la version précédente du code est toujours présente, sous une forme textuelle, cela vous fera gagner beaucoup de temps, car vous n'aurez pas besoin de recourir à des méthodes complexes, difficiles à utiliser. -contrôle et donc très-pronation d'erreur des processus d'utilisation de "fusion partielle de source" et "consolidation de source partielle". que votre outil de contrôle de version peut vous offrir.

Les personnes qui n’aiment pas cette réalité doivent sûrement avoir passé toute leur carrière à ne produire que du code qui n’a jamais été "pas tout à fait mauvais, mais pas tout à fait bon non plus", ou en d’autres termes, ne produisant que du code tout à fait mauvais ou tout à fait parfait. Et nous savons tous quelle est la probabilité d’atteindre ce dernier objectif.