Comment trouvez-vous la mise en page normalement les régions d'une classe?
-
16-10-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
Je me demandais s'il y avait une norme pour la pose des régions d'une classe.
J'utilise actuellement
Fields
Constructor
Properties
Public Methods
Private Methods
Fields étant des propriétés privées et Properties étant les publics. Je vais normalement utiliser les sous-régions dans ce cas de besoin, ou à l'occasion d'ajouter d'autres vais régions ci-dessous (telles que l'interface ou les membres BaseClass).
La solution
Classe liée Enums ou parfois struct / cours pure données (ci-dessus définition de classe réelle)
--- définition de classe ---
Les membres privés
cteurs / DTORs si la langue a DTORs
Propriétés publiques
Méthodes utilitaires (méthodes privées ou protégées avec petit champ)
fonctionnalité de classe (peut être divisée en plusieurs régions en fonction de la portée de la classe).
Autres conseils
Je voulais juste confirmer que vous vouliez dire « #regions » et non la mise en page de classe en général.
Je suis surpris que personne n'a mentionné d'éviter d'utiliser les régions. Je comprends l'OP veut prendre un sondage sur la pose des régions, mais je voudrais soulever un point de vue alternatif.
J'évite les régions. J'aime voir le code, je travaille avec. Si vous trouvez qu'il est difficile de trouver ce que vous cherchez, pliage de code d'utilisation et de groupe des constructions de classes similaires.
Pourquoi est-ce que je déteste les régions? CTRL + M, L et CTRL + M, O permet de basculer le pliage de code. Toutefois, lorsque l'effondrement il cache toute la région. Je dois seulement l'effondrement méthodes / propriétés / commentaires.
S'il y a trop de régions peut-être son une odeur de code et votre classe fait trop de travail. Jeff Atwood offre un bon poste sur régions qui est lu une valeur d'un.
Ma citation préférée sur #regions:
Non, je ne vais pas utiliser #regions. Et non, je ne NÉGOCIER AVEC LES TERRORISTES. Tais-toi.
Cela étant dit, je sais que beaucoup de programmeurs insistent sur leur utilisation. Cette question est subjective. Je pensais juste que j'offrir une alternative.
Il varie d'une langue à. Depuis que je suis un codeur Delphi, j'ai tendance à suivre la convention standard Delphi, qui ressemble à ceci:
type
TMyClass = class(TBaseClass)
private
private fields
private methods
protected
protected fields
protected methods
protected properties
public
constructor(s)
destructor
public methods
public properties
end;
Je trouve une bonne façon d'organiser l'information qui est facile à lire et à comprendre.
J'ai tendance à les poser de la manière suivante:
Public fields (usually static constants)
Constructors
Public methods
Private methods
Private fields
n'ont pas utilisé une langue utilisation Properties c'est pourquoi ce ne sont pas disposés. Je mets des méthodes privées et les champs en bas parce que si quelqu'un d'autre utilise ce fichier dans leur code, ils ne devraient avoir besoin de se préoccuper de l'API, qui est la substance publique. Et tous les éditeurs de texte que je connais, et même IDEs, place le curseur en haut pour ouvrir les fichiers.
Il est un jugement pour moi. J'utilise les régions où ils sont nécessaires pour une meilleure lisibilité.
J'utilise aussi une couleur différente dans mon schéma de couleurs Visual Studio (actuellement un rouge foncé) pour les faire se démarquer du reste du code.
Un exemple d'où je pourrais utiliser un #region: Si j'écris une méthode d'essai pour un test unitaire qui nécessite un extrait plusieurs lignes de XML, la chaîne XML brisera l'empreinte habituelle (car il commence le long de la gauche marge de la fenêtre de code. Pour cacher la laideur, je vais l'envelopper dans un #region, pour que je puisse la réduire.
- La plupart des tentatives de variables et méthodes groupe par la visibilité et la propreté Ne pas faire beaucoup de sens, et vous amener à naviguer autour du code beaucoup.
- Garder les méthodes qui appellent l'autre verticalement réduit près la quantité de navigation que vous devez faire, et il est plus facile de trouver des choses.
- Votre train de pensée ne va pas être brisée si vous devez arrêter et penser « quelle région le fait peu de code appartiennent à? » toutes les quelques minutes.
- les variables d'instance devraient généralement peu nombreux, et susceptibles d'être utilisés partout, par conséquent, ils appartiennent au sommet de la classe où ils seront les plus faciles à localiser. Les variables et les déclarations qui ne seront utilisées que par un besoin de méthode d'exister à l'intérieur de cette méthode. Si elle est utilisée par seulement deux méthodes, alors ils devraient être verticalement à proximité, mais au-dessus des quelques méthodes qui les utilisent.
Garder votre code arrangé avec des éléments qui interagissent généralement verticalement rapprochés élimine efficacement besoin de créer des régions spécifiques. Si votre code est si longue qu'il faut régions cacher beaucoup de code, alors peut-être que est une odeur de code indiquant que la classe essaie d'en faire trop. Peut-être que certaines des fonctionnalités peut être déplacé vers une classe utilitaire, ou poussé jusqu'à un ancêtre.
Si vous avez besoin de « cacher » le code parce qu'il est trop long ou trop « laid », alors vous avez probablement de plus gros problèmes à se soucier de savoir si ou non aux régions d'utilisation. Personnellement, je dois ne jamais les utiliser, et lorsque vous travaillez sur quelqu'un d'autre code, je trouve que je dois toujours les ouvrir de toute façon, alors pourquoi?
I cours actuellement mise en page comme ceci:
class types
constructors
destructor
accessors
methods
properties (where properties are present in the language)
member variables
et le préfixe puis le niveau d'accès à chaque déclaration (en quelque sorte, groupe parfois par l'accès). Je faisais plus haut niveau de regroupement par l'accès, mais à somepoint, je ne sais pas quand, ça ne fonctionnait pas aussi bien que ce qui précède. Par exemple, en C ++ / CLI (que je suis obligé d'utiliser au moment :-() vous pouvez faire cela, ce qui endommagerait le groupement par l'accès:
public: property int SomeProperty
{
private: void set (int value) { ... }
public: int get () { ... }
}
lunatic fringe Réponse: Je ne sais pas, au moins en matière de C #. Entre Visual Studio et R # Je peux magie naviguer à tout membre ou la mise en œuvre donc il n'y a aucun point obsédé par ce genre de choses; il suffit de commencer à taper où le curseur est.
Comme Wyatt et quelques autres réponses, j'évite aussi généralement l'utilisation des régions. Les régions ont un but; au code cacher que vous ne voulez pas avoir à regarder. Si vous avez beaucoup de code dans une classe que vous ne voulez pas avoir à regarder, et donc vous avez besoin de beaucoup de régions pour vous permettre de l'effondrement dudit code, alors vous avez probablement trop de code dans la classe. ReSharper ne respecte pas les régions au moment de décider où placer le nouveau code, à moins qu'il a créé la région (ce qu'il fait pour les implémentations d'interface).
L'une des utilisations des régions que je trouve acceptable est de cacher le code « laid inéluctablement »; Code qui porte sur les modalités de mise en œuvre spécifiques qui ne peuvent pas être bien architecturé en interne aux normes en vigueur. Ceci est généralement avancé, le code ésotérique qui ne devrait généralement pas être sali avec le programmeur junior moyenne une fois par écrit. Ce sont des choses comme:
- Certains intégrés dans les implémentations d'interface (IDisposable, IConvertible, parfois IEnumerable ou IComparable car ils nécessitent des versions génériques et non génériques)
- Embarqué P externs / Invoke et structures connexes.
- Finaliseurs / (Destructeurs vont habituellement de pair IDisposable)
- Crochets à la mémoire non gérés / pointeurs / code "dangereux".
