Que pensez-vous du pliage de code ?[fermé]

Question

Pour ceux d'entre vous qui travaillent dans l'environnement Visual Studio, que pensez-vous de l'encapsulation de votre code dans des #regions ?(ou si un autre IDE a quelque chose de similaire...)

Answer 1

9 fois sur 10, le pliage de code signifie que vous n'avez pas réussi à utiliser le Principe du SoC pour ce que ça vaut.
Je ressens plus ou moins la même chose à propos des cours partiels.Si vous avez un morceau de code que vous jugez trop volumineux, vous devez le découper en parties gérables (et réutilisables), et non le cacher ou le diviser.
Il vous mordra la prochaine fois que quelqu'un aura besoin de le changer et ne pourra pas voir la logique cachée dans une méthode monstre de 250 lignes.

Chaque fois que vous le pouvez, extrayez du code de la classe principale et vers une classe d'assistance ou d'usine.

foreach (var item in Items)
{
    //.. 100 lines of validation and data logic..
}

n'est pas aussi lisible que

foreach (var item in Items)
{
    if (ValidatorClass.Validate(item))
        RepositoryClass.Update(item);
}

Mon 0,02 $ de toute façon.

Answer 2

On en a parlé le Horreur de codage.

Ma conviction personnelle est qu'ils sont utiles, mais comme tout excès, cela peut être trop.

Je l'utilise pour classer mes blocs de code dans :
Énumérations
Déclarations
Constructeurs
Méthodes
Gestionnaires d'événements
Propriétés

Answer 3

Parfois, vous pourriez vous retrouver à travailler dans une équipe où les #régions sont encouragées ou requises.Si vous êtes comme moi et que vous ne supportez pas de jouer avec du code plié, vous pouvez désactiver le mode plan pour C# :

1. Options -> Editeur de texte -> C# -> Onglet Avancé
2. Décochez "Entrer en mode Plan lorsque les fichiers sont ouverts"

Answer 4

J'utilise #Region pour masquer le code généré automatiquement laid et inutile, qui appartient réellement à la partie générée automatiquement de la classe partielle.Mais lorsque vous travaillez avec d'anciens projets ou des projets mis à niveau, vous n'avez pas toujours ce luxe.

Comme pour les autres types de pliage, je plie tout le temps les fonctions.Si vous nommez bien la fonction, vous n'aurez jamais à regarder à l'intérieur à moins de tester quelque chose ou de le (ré)écrire.

Answer 5

Bien que je comprenne le problème que Jeff, et.Al.j'ai avec les régions, ce que je ne le faites pas comprendre c'est pourquoi frapper CTRL+M,CTRL+L étendre toutes les régions d'un fichier est très difficile à gérer.

Answer 6

j'utilise Ami de texte (Mac uniquement) qui a le pliage de code et je le trouve vraiment utile pour les fonctions de pliage, je sais ce que fait ma fonction "getGet", je n'ai pas besoin qu'elle occupe 10 lignes d'un espace d'écran si précieux.

Je ne l'utilise jamais pour masquer une boucle for, une instruction if ou similaire, à moins de montrer le code à quelqu'un d'autre où je cacherai le code qu'il a vu pour éviter d'afficher deux fois le même code.

Answer 7

Je préfère les classes partielles plutôt que les régions.

L’utilisation intensive des régions par d’autres me donne également l’impression que quelqu’un, quelque part, viole le principe de responsabilité unique et essaie de faire trop de choses avec un seul objet.

Answer 8

@À M

Des classes partielles sont fournies afin que vous puissiez séparer le code généré automatiquement par l'outil de toutes les personnalisations que vous pourriez avoir besoin d'effectuer une fois que la génération de code a fait sa part.Cela signifie que votre code reste intact après avoir réexécuté le codegen et n'est pas écrasé.C'est une bonne chose.

Answer 9

Je ne suis pas fan des cours partiels - j'essaie de développer mes cours de telle sorte que chaque cours ait un problème unique et très clair dont il est responsable.À cette fin, je ne crois pas que quelque chose ayant une responsabilité claire devrait être réparti entre plusieurs dossiers.C'est pourquoi je n'aime pas les cours partiels.

Cela dit, je suis hésitant en ce qui concerne les régions.Pour la plupart, je ne les utilise pas ;cependant, je travaille chaque jour avec du code qui inclut des régions - certaines personnes y vont très fort (repliant des méthodes privées dans une région, puis chaque méthode repliée dans sa propre région), et d'autres y vont à la légère (repliant des énumérations, replier les attributs, etc.).Ma règle générale, pour l'instant, est que je ne mets du code dans les régions que si (a) les données sont susceptibles de rester statiques ou ne seront pas touchées très souvent (comme les énumérations), ou (b) s'il existe des méthodes qui sont implémentés par nécessité en raison de sous-classes ou de l'implémentation de méthodes abstraites, mais, encore une fois, ne seront pas abordés très souvent.

Answer 10

Les régions ne doivent jamais être utilisées dans des méthodes.Ils peuvent être utilisés pour regrouper des méthodes mais cela doit être manipulé avec une extrême prudence afin que le lecteur du code ne devienne pas fou.Cela ne sert à rien de plier les méthodes par leurs modificateurs.Mais parfois, le pliage peut améliorer la lisibilité.Par ex.regrouper certaines méthodes que vous utilisez pour résoudre certains problèmes lorsque vous utilisez une bibliothèque externe et que vous ne voudrez pas visiter trop souvent peut être utile.Mais le codeur doit toujours rechercher des solutions, comme envelopper la bibliothèque avec les classes appropriées dans cet exemple particulier.Lorsque tout le reste échoue, utilisez le pliage pour améliorer la lisibilité.

Answer 11

Ce n’est qu’une de ces discussions idiotes qui ne mènent nulle part.Si vous aimez les régions, utilisez-les.Si ce n'est pas le cas, configurez votre éditeur pour les désactiver.Là, tout le monde est content.

Answer 12

Le repliement des régions serait parfait si je n'avais pas à gérer manuellement les regroupements de régions en fonction des fonctionnalités de mon code qui sont intrinsèques au langage.Par exemple, le compilateur sait déjà qu'il s'agit d'un constructeur.Le modèle de code de l'EDI sait déjà qu'il s'agit d'un constructeur.Mais si je veux voir une vue du code où les constructeurs sont regroupés, pour une raison quelconque, je dois réaffirmer le fait que ces éléments sont des constructeurs, en les plaçant physiquement ensemble, puis en formant un groupe autour d'eux.Il en va de même pour toute autre façon de découper une classe/structure/interface.Que se passe-t-il si je change d'avis et que je souhaite voir les éléments publics/protégés/privés d'abord séparés en groupes, puis regroupés par type de membre ?

Utiliser des régions pour délimiter des propriétés publiques (par exemple) est aussi mauvais que de saisir un commentaire redondant qui n'ajoute rien à ce qui est déjà perceptible dans le code lui-même.

Quoi qu'il en soit, pour éviter d'avoir à utiliser des régions à cette fin, j'ai écrit un complément IDE Visual Studio 2008 gratuit et open source appelé Ora.Il fournit automatiquement une vue groupée, ce qui rend beaucoup moins nécessaire le maintien d'un regroupement physique ou l'utilisation de régions. Vous pourriez le trouver utile.

Answer 13

Je trouve généralement que lorsque je traite du code comme des événements en C# où il y a environ 10 lignes de code qui ne font en réalité qu'une partie d'une déclaration d'événement (la classe EventArgs, la déclaration de délégué et la déclaration d'événement) Mettre une région autour d'eux puis les déplier du chemin le rend un peu plus lisible.

Answer 14

Je pense que c'est un outil utile, lorsqu'il est utilisé correctement.Dans de nombreux cas, j’estime que les méthodes, les énumérations et autres choses qui sont souvent pliées devraient être de petites boîtes noires.À moins que vous ne deviez les consulter pour une raison quelconque, leur contenu n'a pas d'importance et doit être aussi caché que possible.Cependant, je ne replie jamais de méthodes privées, de commentaires ou de classes internes.Les méthodes et les énumérations sont vraiment les seules choses que je plie.

Answer 15

Mon approche est similaire à quelques autres ici, utilisant des régions pour organiser les blocs de code en constructeurs, propriétés, événements, etc.

Il existe un excellent ensemble de macros VS.NET de Roland Weigelt disponible sur son article de blog, Meilleure prise en charge du clavier pour la #région...#endregion.Je les utilise depuis des années, en mappant ctrl+.pour réduire la région actuelle et ctrl++ pour l'agrandir.Trouvez que cela fonctionne beaucoup mieux que la fonctionnalité VS.NET par défaut qui plie/déplie tout.

Answer 16

Personnellement, j'utilise #Regions tout le temps.Je trouve que cela m'aide à garder des éléments comme les propriétés, les déclarations, etc. séparés les uns des autres.

C'est probablement aussi une bonne réponse !

Horreur de codage

Modifier:Bon sang, Pat m'a devancé !

Answer 17

Je préfère moi-même les #régions, mais un ancien collègue ne supportait pas que des choses soient cachées.J'ai compris son point de vue une fois que j'ai travaillé sur une page avec 7 #régions, dont au moins 3 avaient été générées automatiquement et portaient le même nom, mais en général je pense qu'elles sont un moyen utile de diviser les choses et de tout garder moins encombré.

Answer 18

Je n'ai vraiment aucun problème à utiliser #region pour organiser le code.Personnellement, je configure généralement différentes régions pour des éléments tels que les propriétés, les gestionnaires d'événements et les méthodes publiques/privées.

Answer 19

Eclipse effectue lui-même une partie de cela en Java (ou en PHP avec des plugins).Vous permet de plier des fonctions et autres.J'ai tendance à l'aimer.Si je sais ce que fait une fonction et que je ne travaille pas dessus, je n'ai pas besoin de la regarder.

Answer 20

Emacs a un mode mineur pliable, mais je ne le lance qu'occasionnellement.Surtout lorsque je travaille sur une monstruosité héritée d'un autre physicien qui avait visiblement moins d'instructions ou qui prenait moins soin de ses pratiques de codage.

Answer 21

Utiliser des régions (ou autrement plier du code) devrait n'ont rien à voir avec les odeurs de code (ou leur masquage) ou toute autre idée de cacher du code que vous ne voulez pas que les gens voient "facilement".

Les régions et le pliage de code consistent en réalité à fournir un moyen de regrouper facilement des sections de code qui peuvent être réduites/pliées/masquées pour minimiser la quantité de « bruit » parasite autour de ce sur quoi vous travaillez actuellement.Si vous configurez les choses correctement (c'est-à-dire nommez vos régions de manière utile, comme le nom de la méthode contenue), vous pouvez tout réduire, à l'exception de la fonction que vous êtes en train de modifier, tout en conservant un certain niveau de contexte sans avoir à voir l'autre. lignes de code.

Il devrait probablement y avoir des lignes directrices de bonnes pratiques autour de ces idées, mais j'utilise largement les régions pour fournir une structure standard à mes fichiers de code (je regroupe les événements, les champs à l'échelle de la classe, les propriétés/méthodes privées, les propriétés/méthodes publiques).Chaque méthode ou propriété possède également une région, où le nom de la région est le nom de la méthode/propriété.Si j'ai un tas de méthodes surchargées, le nom de la région est la signature complète, puis ce groupe entier est enveloppé dans une région qui n'est que le nom de la fonction.

Answer 22

Personnellement, je déteste les régions.Le seul code qui devrait être dans les régions à mon avis est le code généré.Lorsque j'ouvre un fichier, je commence toujours par Ctrl+M+O.Cela se replie au niveau de la méthode.Lorsque vous avez des régions, vous ne voyez que les noms des régions.

Avant d'enregistrer, je regroupe logiquement les méthodes/champs pour que tout semble correct après Ctrl+M+O.Si vous avez besoin de régions, vous devez avoir trop de lignes dans votre classe.Je trouve aussi que c'est très courant.

région Cela ressemble à un code bien organisé parce que j'utilise des régions

// c'est un déchet total, pas de structure ici

région finale

Answer 23

Énumérations

Propriétés

.cteurs

Méthodes

Gestionnaires d'événements

C'est pour cela que j'utilise les régions.Je ne savais pas que vous pouviez les utiliser dans des méthodes.

Cela semble être une très mauvaise idée :)

Answer 24

Le Horreur de codage l'article m'a fait réfléchir à cela aussi.

Généralement, dans les grandes classes, je placerai une région autour des variables, constantes et propriétés membres pour réduire la quantité de texte que je dois parcourir et laisser tout le reste en dehors d'une région.Sur les formulaires, je regroupe généralement les éléments en « variables membres, constantes et propriétés », fonctions de formulaire et gestionnaires d'événements.Encore une fois, c'est plus pour ne pas avoir à faire défiler beaucoup de texte lorsque je souhaite simplement consulter certains gestionnaires d'événements.