Contour C#. accolades ou régions

Question

Je maintiens une grande application asp.net.

Mon objectif est d'identifier les lignes ajoutées en réponse à des tickets particuliers. Bien qu'il soit possible d'utiliser notre SVN, je veux le mettre dans le code. parce que ces changements sembleraient bizarre à un lecteur de première fois du code.

donc la méthode décrivant plus appropriée à cet effet

{ 
//response to ticket #xxxxx 
... 
... 
.. 
} 

OU

#region response to ticket xxxxx 
.. 
... 
.. 
#endregion 

Ou est-il une autre méthode plus adaptée pour cette

Answer 1

Entre les deux, utilisez certainement des commentaires - Ils sont très flexibles. Les régions ne sont pas bonnes pour ce genre de chose - et si plusieurs tickets nécessitent des changements de code qui se chevauchent? C'est facilement expliqué dans un commentaire plus long.

Cependant, je me disputerais de mettre ce genre d'information dans les commentaires de toute façon. Personne ne va vraiment tomber sur du code écrit il y a un an et aller chercher le billet. Code devrait être auto-explicatif, et dans le cas très étrange où il ne l'est pas, les commentaires devraient décrire ce que le code fait effectivement, pas pourquoi. Pour répondre à votre préoccupation spécifique des nouveaux lecteurs - vos collègues n'ont pas besoin de justification pour expliquer pourquoi le code est tel qu'il est. Ils supposeront que c'est ainsi pour une raison, et lorsque vous apporterez des modifications supplémentaires, vous essaierez toujours de conserver les fonctionnalités existantes. C'est un comportement professionnel de base.

Votre changeset doit être associé au # ticket au cas où quelqu'un aurait besoin d'informations historiques. Il y a une liste de justifications pour expliquer pourquoi elles sont stockées dans chaque fichier. Cela est stocké à l'extérieur de votre base de code - soit dans votre contrôle source ou dans un autre référentiel. Dans mon expérience, mettre des numéros de ticket dans le code est généralement un symptôme de mauvaises pratiques. Cela dénote une déviation de la conception au lieu de fixer la conception. Un numéro de billet dit "c'est ainsi que le code était, et c'est ainsi que c'est maintenant." Les bases de code ne doivent pas refléter leur propre histoire - tout ce qui compte, c'est comment elles fonctionnent maintenant. Essayez-en quelques-unes et voyez ce que pensent vos collègues.

Answer 2

Pour tout sauf pour les changements les plus triviaux, vous avez probablement des altérations dispersées dans votre source. Utiliser SVN blame/annotate sera le meilleur choix.

Answer 3

Nous utilisons JIRA plug-in pour SVN pour voir directement quels fichiers de code ont été modifiés pour un ticket particulier.

Les régions peuvent devenir encombrantes car il peut y avoir un cas où une ligne de code est utilisée pour fixer deux tickets. Donc, choisissez le premier ticket #

Answer 4

La première option. "// réponse au billet #xxxxx"

La première fois que vous faites cela ...

int defaultVal = 12; 

A cette ...

int defaultVal = 13; 

Vous détestez votre vie si vous décidez d'un paradigme #region. Les corrections de code à une ou deux lignes sont la norme, et je sais par expérience que l'utilisation excessive de régions perturbe votre flux visuel en cachant des données inutilement.

Il serait préférable de le faire pour cacher les articles que vous savez sont des conneries.

#region Old Code 
//int defaultVal = 12; 
#endregion 
int defaultVal = 13; //Changed by Ticket:13414 

Ceci laisse le nouveau code visible par défaut, et l'ancien code est caché.

Answer 5

Réponse à l'option 1: L'ajout de commentaires pour les tickets diminuerait la lisibilité du code. Je pense (et cela est encouragé dans mon entreprise) que lorsque vous vérifiez un ticket-fix, vous devriez également documenter cette section de code de manière plus appropriée, mais encore une fois, l'ajout d'un numéro de ticket peut être déroutant.

Réponse à l'option 2: Les régions servent à regrouper des fonctions ayant des objectifs similaires, donc je ne recommanderais pas non plus cette option.

Option proposée: Utilisez la /// standard des fonctions de commentaire et ajoutez un élément Ce qui a été modifié. élément. De cette façon, les corrections ne perturbent pas la lisibilité normale, mais il est facile de voir les fonctions impliquées dans les tickets. En prime, ce mécanisme est auto-documenté, de sorte que ceux-ci seraient automatiquement mis dans vos documents générés. Remarque: vous pouvez vérifier que les balises personnalisées sont prises en charge.