Existe-t-il un moyen standard de diviser une classe en régions ?

Question

Je me demandais s'il existe un moyen standard de diviser une classe en régions. Presque chaque projet utilise une "approche par région" différente (même les classes d'un même projet).

Nous accordons tellement d'attention aux conventions de dénomination et si peu à la structure de la classe. Je pense que l'introduction d'une certaine norme nous permettra de nous lancer beaucoup plus facilement dans un nouveau code.

J'utilise par exemple la méthode suivante :

public class SomeClass
{
     #region Consts
     #endregion

     #region Fields
     #endregion

     #region Properties
     #endregion

     #region Construction
     #endregion

     #region Public Methods
     // Class's API
     #endregion

     #region Overrides
     // Different region for each class override
     #endregion

     #region Private Helpers
     // private methods used only to support external API Methods
     #endregion
}

Ceci est pour une classe de base bien sûr. Quand la classe est plus compliquée, plus de régions sont introduites (Destruction, Méthodes Abstraites et ainsi de suite).

Qu'en pensez-vous ? Quelles régions utilisez-vous dans vos cours ?

EDIT

Après avoir lu certaines des réponses, j'ai l'impression que je dois affiner la question (Alt + Enter si vous voyez ce que je veux dire :)) :

Pensez-vous que l'utilisation de régions peut améliorer la lisibilité de votre code ? Si oui, pensez-vous que l'introduction d'une manière standard de le faire simplifiera la façon dont nous lisons le code des autres ?

Une autre édition

A propos de la question de la responsabilité unique - je n'ai pas introduit de régions comme "traitement des fichiers" ou "traitement des entrées". Les régions que j'ai utilisées sont celles qui seront probablement présentes dans n'importe quelle classe que vous écrirez. Parfois, je voudrai voir seulement l'API que cette classe expose et d'autres fois, je voudrai voir seulement les méthodes privées ou les surcharges. encore une fois, dans ce cas, je ne vois pas de mal à cacher un peu de code.

Answer 1

Je vais probablement avoir l'air d'un disque rayé parce que de nombreuses personnes dans ce fil ont déjà exprimé leur opinion contre l'utilisation des régions. Concentrez-vous à rendre votre code plus lisible au lieu de cacher le code. Quand je vois du code qui s'est effondré avec des régions, j'appuie toujours sur Ctrl+M+L pour pouvoir tout voir.

Si une classe est trop grande, c'est un signe que le code doit être revu et probablement principe comme la responsabilité unique doit être appliquée.

Answer 2

Je modèle et organise mes régions, si je les utilise, comme les groupements sur les pages d'aide de la bibliothèque MSDN. Par exemple : Variables membres, propriétés publiques, propriétés privées, constructeurs, destructeurs, méthodes publiques, méthodes protégées, méthodes privées, etc.

Answer 3

Le problème semble être que tous ceux qui s'expriment si ouvertement contre les régions écrivent du code mal organisé (vous pouvez avoir un excellent code, mais mal organisé), et utilisent les régions pour la mauvaise raison, pour cacher le code laid :P

Bien que je sois d'accord pour dire qu'une utilisation excessive peut ajouter au désordre et est contre-productive, je trouve que les utiliser avec modération aide beaucoup à garder les choses organisées et en perspective. La clé est de trouver le bon équilibre.

Answer 4

Envisagez d'utiliser les modèles de Visual Studio pour des choses comme les définitions de classe ou d'interface. Nous les avons créés dans notre entreprise (ce n'est pas difficile à faire) et vous pouvez faire clic droit->addition d'élément->et VS créera une classe vierge avec le format que vous avez spécifié. Voir http://msdn.microsoft.com/en-us/library/ms247121.aspx pour plus d'informations.

Answer 5

Cela dépend beaucoup des préférences personnelles mais je dirais que

• des régions pour regrouper logiquement des éléments comme les méthodes, etc. Cela dépend des préférences mais ce n'est pas une mauvaise chose.
• potentiellement à l'intérieur des méthodes ou pour cacher de gros morceaux de code, etc. est vraiment une mauvaise pratique et vous devriez plutôt envisager de refactorer.