Les # régions sont-elles une odeur de contre-modèle ou de code?
C # permet l'utilisation de #region/#endregion mots clés pour rendre les zones de code réductibles dans l'éditeur. Chaque fois que je fais cela, je le fais pour cacher de gros morceaux de code qui pourraient probablement être refactorisés dans d'autres classes ou méthodes. Par exemple, j'ai vu des méthodes qui contiennent 500 lignes de code avec 3 ou 4 régions juste pour le rendre gérable.
L'utilisation judicieuse des régions est-elle donc un signe de trouble? Il me semble qu'il en soit ainsi.
Une odeur de code est un symptôme qui indique qu'il y a un problème dans la conception qui augmentera potentiellement le nombre de bogues: ce n'est pas le cas pour les régions, mais les régions peuvent contribuer à créer des odeurs de code, comme les méthodes longues.
Depuis:
Un anti-modèle (ou anti-modèle) est un modèle utilisé dans les opérations sociales ou commerciales ou l'ingénierie logicielle qui peut être couramment utilisé mais qui est inefficace et/ou contre-productif dans la pratique
régions sont anti-motifs. Ils nécessitent plus de travail qui n'augmente pas la qualité ou la lisibilité du code, qui ne réduit pas le nombre de bogues, et qui ne peut que rendre le code plus compliqué à refactoriser.
N'utilisez pas de régions dans les méthodes; refactor plutôt
Les méthodes doivent être courtes . S'il n'y a que dix lignes dans une méthode, vous n'utiliseriez probablement pas de régions pour en cacher cinq lorsque vous travaillez sur cinq autres.
De plus, chaque méthode doit faire une et une seule chose . Les régions, d'autre part, sont destinées à séparer les différentes choses . Si votre méthode fait A, alors B, il est logique de créer deux régions, mais c'est une mauvaise approche; à la place, vous devez refactoriser la méthode en deux méthodes distinctes.
L'utilisation de régions dans ce cas peut également rendre la refactorisation plus difficile. Imaginez que vous ayez:
private void DoSomething()
{
var data = LoadData();
#region Work with database
var verification = VerifySomething();
if (!verification)
{
throw new DataCorruptedException();
}
Do(data);
DoSomethingElse(data);
#endregion
#region Audit
var auditEngine = InitializeAuditEngine();
auditEngine.Submit(data);
#endregion
}
Réduire la première région pour se concentrer sur la seconde n'est pas seulement risqué: on peut facilement oublier l'exception arrêtant le flux (il pourrait y avoir une clause de garde avec un return à la place, ce qui est encore plus difficile à repérer), mais aurait également un problème si le code devait être refactorisé de cette façon:
private void DoSomething()
{
var data = LoadData();
#region Work with database
var verification = VerifySomething();
var info = DoSomethingElse(data);
if (verification)
{
Do(data);
}
#endregion
#region Audit
var auditEngine = InitializeAuditEngine(info);
auditEngine.Submit(
verification ? new AcceptedDataAudit(data) : new CorruptedDataAudit(data));
#endregion
}
Maintenant, les régions n'ont aucun sens, et vous ne pouvez pas lire et comprendre le code dans la deuxième région sans regarder le code dans la première.
Un autre cas que je vois parfois est celui-ci:
public void DoSomething(string a, int b)
{
#region Validation of arguments
if (a == null)
{
throw new ArgumentNullException("a");
}
if (b <= 0)
{
throw new ArgumentOutOfScopeException("b", ...);
}
#endregion
#region Do real work
...
#endregion
}
Il est tentant d'utiliser des régions lorsque la validation des arguments commence à s'étendre sur des dizaines de LOC, mais il existe un meilleur moyen de résoudre ce problème: celui utilisé par le code source de .NET Framework:
public void DoSomething(string a, int b)
{
if (a == null)
{
throw new ArgumentNullException("a");
}
if (b <= 0)
{
throw new ArgumentOutOfScopeException("b", ...);
}
InternalDoSomething(a, b);
}
private void InternalDoSomething(string a, int b)
{
...
}
N'utilisez pas de régions en dehors des méthodes pour regrouper
Certaines personnes les utilisent pour regrouper des champs, des propriétés, etc. Cette approche est erronée: si votre code est conforme à StyleCop, alors les champs, propriétés, privés les méthodes, les constructeurs, etc. sont déjà regroupés et faciles à trouver. Si ce n'est pas le cas, il est temps de commencer à penser à appliquer des règles qui garantissent l'uniformité dans votre base de code.
D'autres personnes utilisent des régions pour masquer de nombreuses entités similaires . Par exemple, lorsque vous avez une classe avec cent champs (ce qui fait au moins 500 lignes de code si vous comptez les commentaires et les espaces), vous pouvez être tenté de placer ces champs dans une région, de la réduire et de les oublier. Encore une fois, vous vous trompez: avec autant de champs dans une classe, vous devriez mieux penser à utiliser l'héritage ou diviser l'objet en plusieurs objets.
Enfin, certaines personnes sont tentées d'utiliser des régions pour regrouper des choses liées : un événement avec son délégué, ou une méthode liée à IO avec d'autres méthodes liées aux IO, etc. Dans le premier cas, cela devient un gâchis difficile à maintenir, à lire et à comprendre.Dans le second cas, la meilleure conception serait probablement de créer plusieurs classes.
Y a-t-il une bonne utilisation pour les régions?
Non. Il y avait une utilisation héritée: code généré. Pourtant, les outils de génération de code doivent simplement utiliser des classes partielles à la place. Si C # prend en charge les régions, c'est principalement à cause de cette utilisation héritée, et parce que trop de personnes utilisent des régions dans leur code, il serait impossible de les supprimer sans casser les bases de code existantes.
Pensez-y comme à propos de goto. Le fait que la langue ou la IDE prend en charge une fonctionnalité ne signifie pas qu'elle doit être utilisée quotidiennement. La règle StyleCop SA1124 est claire: vous ne devez pas utiliser jamais.
Exemples
J'effectue actuellement une révision du code de mon collègue. La base de code contient beaucoup de régions et est en fait un parfait exemple à la fois de la façon de ne pas utiliser les régions et pourquoi les régions conduisent à un mauvais code. Voici quelques exemples:
4000 monstre LOC:
J'ai récemment lu quelque part sur Programmers.SE que lorsqu'un fichier contient trop de usings (après avoir exécuté la commande "Remove Unused Usings"), c'est un bon signe que la classe à l'intérieur de ce fichier en fait trop. Il en va de même pour la taille du fichier lui-même.
En examinant le code, je suis tombé sur un fichier LOC 4 000. Il est apparu que l'auteur de ce code a simplement copié-collé la même méthode de 15 lignes des centaines de fois, changeant légèrement les noms des variables et la méthode appelée. Un regex simple a permis de couper le fichier de 4 000 LOC à 500 LOC, simplement en ajoutant quelques génériques; Je suis assez sûr qu'avec une refactorisation plus intelligente, cette classe peut être réduite à quelques dizaines de lignes.
En utilisant des régions, l'auteur s'est encouragé à ignorer le fait que le code est impossible à maintenir et mal écrit, et à dupliquer fortement le code au lieu de le refactoriser.
Région "Do A", Région "Do B":
Un autre excellent exemple était une méthode d'initialisation de monstre qui faisait simplement la tâche 1, puis la tâche 2, puis la tâche 3, etc. Il y avait cinq ou six tâches qui étaient totalement indépendantes, chacune initialisant quelque chose dans une classe de conteneur. Toutes ces tâches ont été regroupées en une seule méthode et regroupées en régions.
Cela avait un avantage:
- La méthode était assez claire à comprendre en regardant les noms de région. Cela étant dit, la même méthode une fois refactorisée serait aussi claire que l'original.
En revanche, les problèmes étaient multiples:
Ce n'était pas évident s'il y avait des dépendances entre les régions. Espérons qu'il n'y ait pas eu de réutilisation des variables; sinon, l'entretien pourrait être encore plus un cauchemar.
La méthode était presque impossible à tester. Comment sauriez-vous facilement si la méthode qui fait vingt choses à la fois les fait correctement?
Région des champs, région des propriétés, région du constructeur:
Le code révisé contenait également de nombreuses régions regroupant tous les champs, toutes les propriétés ensemble, etc. Cela posait un problème évident: la croissance du code source.
Lorsque vous ouvrez un fichier et voyez une énorme liste de champs, vous êtes plus enclin à refactoriser d'abord la classe, puis à travailler avec du code. Avec les régions, vous prenez l'habitude de vous effondrer et de l'oublier.
Un autre problème est que si vous le faites partout, vous vous retrouverez à créer des régions à un bloc, ce qui n'a aucun sens. C'était en fait le cas dans le code que j'ai examiné, où il y avait beaucoup de #region Constructor contenant un constructeur.
Enfin, les champs, les propriétés, les constructeurs, etc. devraient déjà être en ordre . S'ils le sont et qu'ils correspondent aux conventions (constantes commençant par une majuscule, etc.), il est déjà clair où s'arrête le type des éléments et les autres commencent, vous n'avez donc pas besoin de créer explicitement des régions pour cela.
C'est incroyable pour moi combien de personnes détestent les régions si passionnément!
Je suis entièrement d'accord avec tant de leurs objections: pousser du code dans un #region le cacher n'est pas une bonne chose. Diviser une classe en #regions quand il devrait être refactorisé en classes séparées est clairement une erreur. Utilisant un #region pour incorporer des informations sémantiques redondantes est, eh bien, redondant.
Mais rien de tout cela ne signifie qu'il y a quelque chose intrinsèquement incorrect avec l'utilisation des régions dans votre code! Je peux seulement supposer que les objections de la plupart des gens viennent d'avoir travaillé sur des équipes où d'autres sont enclins à utiliser IDE des fonctionnalités comme celle-ci de manière incorrecte. J'ai le luxe de travailler seul par moi-même, et j'apprécie le façon dont les régions ont aidé à organiser mon flux de travail. C'est peut-être mon trouble obsessionnel-compulsif, mais je n'aime pas voir un tas de code sur mon écran à la fois, peu importe à quel point il peut être écrit avec élégance et élégance. Séparer les choses en régions logiques me permet de réduire le code que je ne me soucie pas de travailler sur le code que je . Je n'ignore pas le code mal écrit, il n'est pas logique de le refactoriser plus qu'il ne l'est, et l'organisation "méta" supplémentaire est descriptive, plutôt que inutile.
Maintenant que j'ai passé plus de temps à travailler en C++, à programmer plus directement sur l'API Windows, je me retrouve à souhaiter que le support pour les régions soit aussi bon que pour C #. Vous pourriez faire valoir que l'utilisation d'une bibliothèque GUI alternative rendrait mon code plus simple ou plus clair, éliminant ainsi la nécessité de supprimer le bruit de code non pertinent de l'écran, mais j'ai d'autres raisons de ne pas vouloir le faire. Je suis assez compétent avec mon clavier et IDE que développer/réduire le code subdivisé en régions prend moins d'une fraction de seconde. Le temps que j'économise en cervelle, en essayant de limiter ma concentration consciente seul le code sur lequel je travaille actuellement en vaut la peine. Tout appartient à une seule classe/fichier, mais il n'appartient pas à mon écran en même temps.
Le fait est que l'utilisation de #regions pour séparer et diviser logiquement votre code n'est pas une mauvaise chose à éviter à tout prix. Comme le souligne Ed, ce n'est pas une "odeur de code". Si votre code sent, vous pouvez être sûr qu'il ne provient pas des régions, mais plutôt du code que vous avez essayé d'enfouir dans ces régions. Si une fonctionnalité vous aide à être plus organisé ou à écrire un meilleur code, alors je dis tilisez-le. Si cela devient un obstacle ou si vous vous en servez de manière incorrecte, alors stop l'utilisez. Si le pire arrive au pire et que vous êtes obligé de travailler en équipe avec des personnes qui l'utilisent, mémorisez le raccourci clavier pour désactiver le code décrivant: Ctrl+M, Ctrl+P. Et arrête de te plaindre. Parfois, j'ai l'impression que c'est une autre façon pour ceux qui veulent être considérés comme de "vrais" programmeurs "hardcore" d'essayer de faire leurs preuves. Il vaut mieux éviter les régions que d'éviter la coloration syntaxique. Cela ne fait pas de vous un développeur plus macho.
Tout cela étant dit, les régions à l'intérieur d'une méthode sont tout simplement absurdes. Chaque fois que vous vous retrouvez à vouloir faire cela, vous devriez refactoriser une méthode distincte. Pas d'excuses.
Tout d'abord, je ne supporte plus le terme "odeur de code". Il est utilisé trop souvent et est souvent utilisé par des personnes qui ne pourraient pas reconnaître un bon code s'il les mordait. Quoi qu'il en soit ...
Personnellement, je n'aime pas utiliser beaucoup de régions. Cela rend plus difficile l'accès au code, et c'est le code qui m'intéresse. J'aime les régions quand j'ai un gros morceau de code qui n'a pas besoin d'être touché très souvent. En dehors de cela, ils semblent juste me gêner, et des régions comme "Méthodes privées", "Méthodes publiques", etc. me rendent fou. Ils s'apparentent aux commentaires de la variété i++ //increment i.
J'ajouterais également que l'utilisation de régions ne peut pas vraiment être un "anti-modèle" car ce terme est couramment utilisé pour décrire la logique de programme/modèles de conception, pas la mise en page d'un éditeur de texte. C'est subjectif; utilisez ce qui vous convient. Vous n'allez jamais vous retrouver avec un programme impossible à entretenir en raison de votre surutilisation des régions, c'est à cela que servent les anti-modèles. :)
Oui, les régions sont une odeur de code!
Je serais heureux de voir les régions supprimées du compilateur. Chaque développeur propose son propre schéma de nettoyage inutile qui ne sera jamais utile à un autre programmeur. J'ai tout à voir avec les programmeurs qui veulent décorer et embellir leur bébé, rien à voir avec une réelle valeur.
Pouvez-vous penser à un exemple où vous vous êtes dit "bon sang, j'aurais aimé que mon collègue utilise certaines régions ici!"?
Même si je peux configurer mon IDE pour étendre automatiquement toutes les régions, ils sont toujours douloureux et nuisent à la lecture du vrai code.
Je m'en soucierais vraiment moins si toutes mes méthodes publiques étaient regroupées ou non. Félicitations, vous connaissez la différence entre une déclaration de variable et l'initialisation, pas besoin de l'afficher en code!
Toilettage sans valeur!
De plus, si votre fichier a besoin d'une "architecture de l'information" grâce à l'utilisation de régions, vous voudrez peut-être combattre le problème principal: votre classe est beaucoup trop grande! La diviser en parties plus petites est beaucoup plus bénéfique et, lorsqu'elle est effectuée correctement, ajoute une véritable sémantique/lisibilité.
J'utilise personnellement les régions comme moyen de regrouper différents types de méthodes ou parties de code.
Ainsi, un fichier de code pourrait ressembler à ceci lors de son ouverture:
- Propriétés publiques
- Constructeurs
- Enregistrer les méthodes
- Modifier les méthodes
- Méthodes d'assistance privée
Je ne mets pas les régions à l'intérieur des méthodes. À mon humble avis, c'est un signe d'odeur de code. Une fois, je suis tombé sur une méthode de plus de 1 200 lignes et contenant 5 régions différentes. C'était un spectacle effrayant!
Si vous l'utilisez comme un moyen d'organiser votre code d'une manière qui rendra les choses plus rapides pour les autres développeurs, je ne pense pas que ce soit un signe de problème. Si vous l'utilisez pour masquer des lignes de code à l'intérieur d'une méthode, je dirais qu'il est temps de repenser cette méthode.
En utilisant #region des blocs pour rendre une classe très grande lisible est généralement un signe de violation du principe de responsabilité unique. S'ils sont utilisés pour regrouper le comportement, alors c'est aussi probablement que la classe en fait trop (violant encore une fois SRP).
Fidèle à la ligne de pensée "odeur de code", #region les blocs ne sont pas des odeurs de code en soi, mais plutôt des "Febreze pour le code" en ce sens qu'ils essaient de cacher les odeurs. Alors que je les ai utilisés une tonne dans le passé, lorsque vous commencez à refactoriser, vous commencez à en voir moins car ils finissent par ne pas cacher beaucoup.
Le mot clé ici est "judicieux". Il est difficile d'imaginer un cas où mettre une région à l'intérieur d'une méthode est judicieux; cela est trop susceptible d'être caché et paresseux. Cependant, il peut y avoir de bonnes raisons d'avoir quelques régions ici et là dans son code.
S'il y a beaucoup, beaucoup de régions, je pense que c'est une odeur de code. Les régions sont souvent un indice d'un endroit possible pour une refactorisation future. Beaucoup de régions signifient que quelqu'un ne prend jamais en compte l'indice.
Utilisés judicieusement, ils offrent un bon compromis entre la structure d'une classe unique avec de nombreuses méthodes et la structure de nombreuses classes avec seulement quelques méthodes dans chacune. Ils sont plus utiles lorsqu'une classe commence à se rapprocher du point où elle devrait être refactorisée en plusieurs classes, mais n'est pas encore là. En regroupant les méthodes connexes, je facilite plus tard l'extraction d'un ensemble de méthodes connexes dans leur propre classe si elles continuent de croître en nombre. Par exemple, si j'ai une classe qui approche de 500 lignes de code, cet ensemble de méthodes utilisant 200 lignes de code collectées ensemble dans une région est probablement une bonne pièce à refactoriser d'une manière ou d'une autre - et cette autre région avec 100 lignes de code dans son les méthodes pourraient également être une bonne cible.
Une autre façon dont j'aime utiliser les régions est de réduire l'un des effets négatifs de la refactorisation d'une grande méthode: un bon nombre de petites méthodes concises et facilement réutilisables qu'un lecteur doit parcourir pour accéder à une autre méthode presque indépendante. Une région peut être un bon moyen de méta-encapsuler une méthode et ses aides pour les lecteurs, donc quelqu'un qui travaille avec un aspect différent de la classe peut simplement les réduire et rejeter rapidement cette partie du code. Bien sûr, cela ne fonctionne que si vos régions sont vraiment bien organisées et utilisées essentiellement comme un autre moyen de documenter votre code.
En général, je trouve que les régions m'aident à rester organisé, à "documenter" mon code et à trouver des endroits à refactoriser beaucoup plus tôt que si je n'utilise pas les régions.
J'utilise principalement les régions pour les classes de serveur CRUD pour organiser les différents types d'opérations. Même alors, je pouvais volontiers m'en passer.
Si elle est largement utilisée, elle déclencherait un drapeau rouge. Je serais à la recherche de classes qui ont trop de responsabilités.
D'après mon expérience, une méthode avec des centaines de lignes, un code est définitivement une odeur.
Ma règle d'or est: Si vous avez plus de 5 régions dans un fichier, c'est une odeur de code
C'est-à-dire qu'il pourrait être bien de délimiter un champ, des méthodes, des propriétés et des constructeurs, mais si vous commencez à envelopper toutes les autres méthodes dans une région qui lui est propre, quelque chose ne va vraiment pas
..et oui, j'ai été sur de nombreux projets où c'est le cas, souvent à cause de mauvaises normes de codage, de la génération de code ou des deux. Il est très rapide de devoir basculer tous les contours dans Visual Studio pour obtenir un bon aperçu du code.
LES RÉGIONS ONT LEUR UTILISATION
Je les ai utilisés personnellement pour les événements d'interface de "codage manuel" auparavant pour les applications Windows Forms.
Cependant, dans mon travail, nous utilisons un générateur de code pour gérer SQL et il utilise automatiquement les régions pour trier ses types de méthodes de sélection, de mise à jour, de suppression, etc.
Donc, même si je ne les utilise pas souvent, ils conviennent parfaitement pour supprimer de gros morceaux de code.
Si vous avez des régions DANS LE CODE , vous avez certainement un problème (sauf dans le cas du code généré).
Cependant, il existe d'autres cas. Celui qui me vient à l'esprit que j'ai fait il y a quelque temps: une table contenant quelques milliers d'éléments précalculés. C'est une description de la géométrie, à moins d'une erreur dans le tableau il n'y aura jamais l'occasion de la regarder. Bien sûr, j'aurais pu obtenir les données d'une ressource ou similaire, mais cela empêcherait d'utiliser le compilateur pour faciliter la lecture.
Je dirais que c'est une "odeur de code".
Les anti-motifs sont généralement des problèmes structurels fondamentaux dans un logiciel, tandis que les régions, à elles seules, provoquent un comportement désagréable dans un éditeur. L'utilisation de régions n'est pas en soi mauvaise en soi, mais les utiliser beaucoup, en particulier pour masquer des morceaux de code, peut indiquer qu'il existe d'autres problèmes, indépendants et plus importants, ailleurs.
Sur un projet récent, il y avait une méthode de 1700 lignes avec plusieurs régions intégrées. Ce qui est intéressant, c'est que les régions ont défini des actions distinctes qui étaient effectuées dans le cadre de la méthode. J'ai pu faire un refactor -> extraire la méthode sur chacune des régions sans impact sur la fonctionnalité du code.
En général, les régions utilisées pour masquer le code de plaque de chaudière sont utiles. Je déconseille d'utiliser des régions pour masquer des propriétés, des champs, etc., car si elles sont trop lourdes à regarder lorsque vous travaillez au sein de la classe, c'est probablement un signe que la classe devrait être davantage ventilée. Mais en règle générale, si vous placez une région dans une méthode, vous feriez probablement mieux d'extraire une autre méthode qui explique ce qui se passe que d'envelopper ce bloc dans une région.
Les régions peuvent-elles être utilisées dans un code de bonne qualité? Probablement. Je parie que oui, dans de nombreux cas. Cependant, mon expérience personnelle me laisse très suspecte - j'ai vu des régions presque exclusivement mal utilisées. Je dirais que je suis blasé, mais toujours optimiste.
Je peux à peu près diviser le code utilisant la région que j'ai vu à ce jour en trois catégories:
Code mal factorisé: la plupart du code que j'ai vu utilise les régions comme outil de factorisation du pauvre. Par exemple, une classe qui a grandi au point où il est logique de la spécialiser à des fins différentes peut être divisée en régions distinctes, une pour chaque fin.
Code écrit en utilisant les mauvaises bibliothèques, et parfois la mauvaise langue, pour le domaine problématique Souvent, lorsqu'un programmeur n'utilise pas le bon ensemble de bibliothèques pour le domaine problématique, vous verrez le code devenir incroyablement verbeux - avec beaucoup de petites fonctions d'aide qui n'appartiennent pas vraiment (ils appartiennent probablement à leur propre bibliothèque).
Code écrit par des étudiants ou des diplômés récents. Certains programmes et cours semblent essayer d'inculquer aux étudiants l'utilisation des régions à toutes sortes de fins étranges. Vous verrez des régions joncher le code source au point où le rapport des balises de région aux lignes de code est de l'ordre de 1: 5 ou pire.
J'utilise les régions pour une seule chose (au moins, je ne peux pas penser à d'autres endroits où je les utilise): pour regrouper les tests unitaires d'une méthode.
J'ai généralement une classe de test par classe, puis je regroupe les tests unitaires pour chaque méthode en utilisant des régions qui portent le nom de la méthode. Je ne sais pas si c'est une odeur de code ou quoi que ce soit, mais comme l'idée de base est que les tests unitaires n'ont pas besoin de changer à moins qu'ils ne se cassent parce que quelque chose dans le code a changé, il est plus facile pour moi de trouver tous les tests pour une méthode spécifique assez rapidement.
J'ai peut-être utilisé des régions pour organiser le code dans le passé, mais je ne me souviens pas de la dernière fois que je l'ai fait. Je reste fidèle à mes régions dans les classes de tests unitaires.
Je pense que c'est un modèle anti et pense franchement qu'ils devraient être éliminés. Mais si vous êtes dans la situation malheureuse de travailler dans un endroit où ils sont un Visual Studio standard offre un outil génial pour minimiser la quantité que vous aimeriez vomir chaque fois que vous voyez une région je déteste les # régions
Ce plugin maximisera la taille de police des régions vraiment petites. Ils seront également développés afin que vous n'ayez pas à appuyer sur ctr + m + l pour ouvrir toutes les régions. Il ne corrige pas cette forme de cancer du code, mais il le rend supportable.
Les régions étaient une idée organisationnelle astucieuse, mais n'ont pas pris en compte certaines tendances des développeurs à vouloir sur-catégoriser tout, et généralement inutiles selon la plupart des temps modernes OOP pratiques ... elles sont une "odeur" , dans le sens où les utiliser indique souvent que votre classe/méthode est beaucoup trop grande et doit être refactorisée, car vous violez probablement le "S" de SOLID principes ... mais comme tout l'odeur, cela ne signifie pas nécessairement que quelque chose va mal.
Les régions ont plus d'intérêt dans le code fonctionnel plutôt que dans le code orienté objet, IMO, où vous avez de longues fonctions de données séquentielles qu'il est logique de rompre, mais il y a eu des moments où je les ai personnellement utilisées en c #, et elles ont presque toujours concentrez-vous sur le code que vous n'avez pas besoin de regarder. Pour moi, il s'agissait généralement de constantes de chaîne SQL brutes dans la base de code utilisée pour NPoco ou ses variantes. À moins que vous ne vous souciez réellement de la façon dont les données viennent remplir l'objet POCO via votre ORM, celles-ci étaient complètement inutiles à regarder ... et si vous vous en souciez, hé, développez simplement la région et BAM! Plus de 150 lignes d'une requête SQL compliquée pour votre plaisir de visionnement.
J'utilise des régions pour contenir chaque combinaison de visibilité et de type de membre. Donc, toutes les fonctions privées vont dans une région, etc.
La raison pour laquelle je fais cela n'est pas pour que je puisse replier le code. C'est parce que mon éditeur est scripté afin que je puisse insérer, disons, une référence à un proxy:
#region "private_static_members"
/// <summary>
/// cache for LauncherProxy
/// </summary>
private static LauncherProxy _launcherProxy;
#endregion
#region "protected_const_properties"
protected LauncherProxy LauncherProxy{
get{
if(_launcherProxy==null) {
if (!God.Iam.HasProxy(LauncherProxy.NAME)) {
God.Iam.RegisterProxy(new LauncherProxy());
}
_launcherProxy=God.Iam.Proxy(LauncherProxy.NAME) as LauncherProxy;
}
return _launcherProxy;
}
}
#endregion
dans le code et que chaque partie soit soigneusement rangée dans la bonne région.
Dans ce cas, la macro analyserait mon projet, me donnerait une liste de proxys et injecterait le code de celui que je veux. Mon curseur ne bouge même pas.
Au début de l'apprentissage du C #, j'avais envisagé l'utilisation des régions pour maintenir la communauté en commun, mais c'est une proposition de hasard, car ce n'est pas une relation un à un en tout temps. Qui veut s'inquiéter d'un membre utilisé par deux régions, ou même commencer à diviser les choses en ces termes.
Le seul autre type de ségrégation est les méthodes - je décomposerai les méthodes en commandes, fonctions et gestionnaires, donc j'aurais une région pour les commandes publiques, privées, etc., etc.
Cela me donne une granularité, mais c'est cohérent, sans équivoque granularité sur laquelle je peux compter.
Les régions sont des expressions de préprocesseur - en d'autres termes, elles sont traitées comme des commentaires et fondamentalement ignorées par le compilateur. Ils sont purement un outil visuel utilisé dans Visual Studio. Par conséquent, #region n'est pas vraiment une odeur de code, car ce n'est tout simplement pas du code. L'odeur de code est plutôt la méthode des 800 lignes qui comporte de nombreuses responsabilités différentes, etc. Si vous voyez 10 régions dans une même méthode, elle est probablement utilisée pour masquer une odeur de code. Cela dit, je les ai vus utilisés de manière extrêmement efficace pour rendre une classe plus agréable à l'œil et plus navigable - dans une classe très bien écrite et structurée aussi!