Laissez-vous le code historique commenté dans les classes que vous mettez à jour?

Question

Lorsque vous avez besoin d'obsolète dans la section de code (dire les règles métier a changé, ou l'ancien système a été retravaillé afin d'utiliser un nouveau cadre ou quelque chose) que pensez-vous de le supprimer à partir du fichier ou avez-vous en commentaire et puis les mettre dans la nouvelle fonctionnalité? Si vous en commentaire, ne vous laissez une note indiquant la raison pour laquelle il a été enlevé et qu'il était à l'origine destiné à faire?

Je demande principalement parce que j'ai fait beaucoup de contrat de travail pour des endroits différents au fil des ans et parfois c'est comme de la fouille d'un tombeau pour trouver le code qui est toujours utilisé. Pourquoi en commentaire et laisser dans le fichier, si la source de contrôle a un dossier de ce que l'habitude d'être là? Si vous commentez une méthode avez-vous aussi un commentaire/supprimer toutes les méthodes qui ont été exclusivement utilisés par cette méthode?

Que pensez-vous des meilleures pratiques pour ce qui devrait être?

Answer 1

J’ai toujours supprimer ancien code : je n’aime pas code malpropre.

Il faut toujours un record avec contrôle de code source.

Answer 2

Supprimer définitivement. Contrôle de code source s’occupe du reste. Si vous avez besoin de la fonctionnalité à nouveau, inverse fusionner dedans. Vous ne voudrez pas le faire manuellement plus x fichiers pour des modifications plus complexes.

Cela a aussi l’avantage que vous pouvez fusionner la suppression sur les autres branches et cette « caractéristique » ou « suppression de la fonctionnalité » obtient isolée dans un ensemble de modifications. Vous n’avez pas ces informations si vous venez commenter... Je ne vois aucune bonne raison de garder le code commenté, beaucoup pour se débarrasser de lui.

Answer 3

cas n ° 1: Si vous avez de contrôle à la source, puis de les supprimer.

cas n ° 2: Si vous n'avez pas de contrôle à la source, puis obtenir le contrôle de la source et de voir le cas n ° 1 ci-dessus.

Pour moi, quand je vois un code commenté, je pense à moi-même que le développeur qui a fait le changement n'était pas sûr qu'il était en train de faire la bonne chose. Il devrait passer le temps de s'assurer, au lieu d'avoir une politique de sauvegarde d'avoir le code commenté pour en revenir à la situation. Et si à la fin vous n'êtes pas sûr si vous êtes en rendant le droit de modifier, mettre un commentaire qui décrit ce que vous avez changé et pourquoi vous n'êtes pas sûr si c'est la bonne façon, et supprimer le code. Ne commentez pas le bloc de code.

Le Code est assez dur à lire et à suivre comme il est, vous ne voulez pas encombrer le code et le rendre encore plus difficile de comprendre ce qu'il est en train de faire de gros blocs de code commenté. Si quelqu'un a besoin de regarder l'histoire qu'il peut regarder l'histoire par le contrôle de source.

parfois, vous devrez ajouter la fonctionnalité et le développeur de l'ajouter de nouveau ne peut pas savoir à case de contrôle à la source de l'histoire

C'est ce que les journaux sont pour dans les systèmes de contrôle de source. Ils vous permettent de rechercher des commentaires et de l'historique des fichiers. Aussi ce qui semble être de plus en plus une préoccupation organisationnelle. Vous pouvez assigner des tâches à plus appropriée aux développeurs ou à avoir des discussions au sein de l'équipe. La personne de l'affectation de la tâche doit savoir à qui l'attribuer ou de référence.

Aussi, si vous pensez que vous serez en les ajoutant à nouveau, consultez votre manager et assurez-vous que vous faites le bon changement pour ce qu'ils veulent faire.

Si vous pensez vraiment qu'une grosse partie du code sera réutilisé à nouveau, vous pouvez branche ou une étiquette à votre référentiel et ensuite faire les modifications. Vous pouvez faire référence à retour vers cette branche ou une étiquette plus tard.

parfois, le code représente la fonctionnalité unique qui peut être une référence utile, de voir tout cela en un seul endroit peut aider à fournir des indices à déchiffrer le code actif.

Créer une sorte de base de connaissances interne ou de référence avec le perspicace code. Avoir une logique où il n'appartient pas plus rend le code plus difficile à lire et à comprendre.

Answer 4

J’ai commentaire code initialement. Quand le nouveau code a été va bon pour quelques versions alors je vais le supprimer.

Les autres gars ici doivent avoir beaucoup meilleur logiciel de contrôle de version que moi. Si je supprime quelque chose, il n’y a aucune indication visuelle de quelque chose de différent n’a jamais été là. Et juste pour voir une ancienne version j’ai commander sur le dessus de ma version actuelle, chargez-le dans l’éditeur, puis re-commander la version la plus récente lorsque j’ai terminé.

Answer 5

Je préfère de le supprimer. De cette façon, elle n’encombre pas jusqu'à l’actuel codefile et quiconque se soucie peut chercher dans contrôle de version.