Pourquoi les régions de code ne sont-elles pas autorisées dans les corps de méthode dans VB.NET?

Question

Normalement, je n'aurais pas "besoin" ou même d'envisager une ridicule comme des régions code dans le corps de méthode, mais: je suis refactoring VB.NET code où les méthodes couramment cinq cents lignes et les références sont si étroitement couplé que le code défie simple comme méthode d'extraction.

Et c'est pourquoi j'ai pensé que je voudrais essayer de régions à l'intérieur d'un corps de méthode. Je voulais juste organiser le code pour le court terme. Mais l'IDE ne m'a pas laissé (a entraîné une erreur de compilation.) Je suis juste curieux de savoir pourquoi? Semble que le code de régions ne devrait pas avoir d'impact pour le compilateur, intellisense, etc. Ai-je raté quelque chose? (Toujours à l'aide de VS 2005 btw.)

Intéressant: Cela semble être spécifique à une langue. C'est OK en C# (je ne l'ai pas vérifié au début), mais pas dans VB.NET.

public module MyModule
    Sub RunSnippet()
        dim a as A = new A (Int32.MaxValue )

        #region 
        Console.WriteLine ("")
        #end region
       ....

qui obtient une erreur de compilation, mais la version de C# est ok.

Answer 1

Je pense que le code de régions ne serait probablement pas être pris en charge dans le corps de méthode car, comme vous le dites, serait (un peu) de "ridicule fonctionnalité" - Toutefois, en C#, ce n' travail, au moins dans VS 2008 et VS 2010 - tout simplement pas dans VB.NET.

Cela étant dit, je voudrais l'éviter. Mettre de régions à l'intérieur d'un corps de méthode serait tout simplement conduit les gens à faire de grands méthodes (puisque c'est le seul moment où il serait utile), ce qui est quelque chose qui doit être évité, n'est pas encouragé.

Si votre code:

défie simple comme méthode d'extraction

Je me concentrerais plutôt sur le fait de faire "complexe" refactoring (ou ce qu'il faut) pour essayer de briser ces méthodes. Il n'y a aucun moyen de votre "quatre ou cinq cents lignes" long méthodes sont toutes maintenues dans leur état actuel.

Personnellement, je voudrais les laisser causer de la douleur" - font qu'il est évident qu'ils ont besoin de travail, avant droite et le centre, jusqu'à ce que vous pouvez casser et refactoriser des parties.

Answer 2

Il est explicite dans le chapitre 3.3 du Visual Basic 9.0 Langue Spécifications:

Région directives du groupe de lignes de code source, mais n'ont aucun autre effet sur la compilation. L'ensemble du groupe s'est effondré et caché, ou agrandi et affiché, dans l'environnement de développement intégré (IDE). Ces directives sont particulières en ce qu'elles ne peuvent ni début ni fin dans un corps de méthode

Ou en d'autres termes: vous ne pouvez pas le faire parce que la spécification dit.

Pourquoi il a été spécifié comme ça, je pense qu'il a quelque chose à voir avec la vieille IDE fonctionnalité que VB a eu pour autant que je me souvienne: Outils + Options, Éditeur de Texte, de Base, VB Spécifiques, Montrer procédure de la ligne de séparation. C'est juste une supposition, probablement pas très bon.

Answer 3

Je ne sais pas pour VB, mais en C # cela est autorisé depuis 1.0 pour autant que je sache.

En effet, vous pouvez même placer des régions de code dans des endroits impairs qui traversent des étendues. Par exemple:

 class Test
{
    static void Main()
    {
        if (DateTime.Now.Hour > 12)
        {
#region Foo
            Console.WriteLine("Afternoon");            
        }
#endregion
    }
}
 

Ici, la région commence dans l'instruction if , mais se termine en dehors de celle-ci. Horrible, mais le compilateur est d'accord avec ça.

Que voulez-vous dire lorsque vous avez dit que l'EDI ne vous «laissait» pas mettre de code dans les régions? Avez-vous eu une erreur de compilation?

Answer 4

Il s'agissait simplement d'un choix de la VB équipe lors de l'ajout de la fonctionnalité de zones dans la version 7 du langage Visual Basic. Il a été considéré comme une fonctionnalité qui a été utile pour l'organisation d'une déclaration et non pas à l'intérieur d'une méthode, et donc seulement à ce niveau.

L'équipe C# sentir différemment à propos de cette fonctionnalité et permettent dans de nombreux autres endroits. J'ai toujours trouvé ça surprenant que C# #region directives peut se produire dans différents déclaration de contextes.

#region Foo
class Bar {
#endregion

}

Le code équivalent n'est pas autorisé dans VB.

Answer 5

Visual Studio 2003 avait pour VB.NET, mais a été supprimée dans Visual Studio 2005 et plus tard. Vraiment gênant quand refactoring grand procédures, mais vous pouvez diviser la fenêtre de code.

Honnêtement, je souhaite C# serait restreindre la région parce qu'ils sont trop utilisés. J'ai une macro qui les prive de tous les fichiers de code lorsque vous héritez projets C#.

Une autre fonctionnalité a été supprimé de la liste des méthodes substituables dans la Barre de Navigation. - Je vérifier pour voir si ils re-ajout de cette fonctionnalité pour chaque nouvelle version de Visual Studio depuis 2005.