Question: **Note**: This "feature" has now been added to Visual Studio 2015 but the question will hold a while since not every developer or every dev shop gets access to the latest and greatest IDE as soon as it comes out.

**ORIGINAL QUESTION:**

Normally I wouldn't "need" or even consider a ridiculous feature such as code regions within method bodies but: I'm refactoring VB.NET code where methods routinely run five hundred lines of code or more and the references are so tightly coupled that the code defies simple refactoring such as method extraction. 

And that's why I thought I would try regions within a method body. I just wanted to organize the code for the short term. But the IDE doesn't let me (resulted in a compiler error.) I'm just curious as to why? Seems like code regions shouldn't impact the compiler, intellisense etc. Am I missing something? (Still using VS 2005 btw.)

**Interesting:** This seems to be language specific. It's OK in C# (I didn't check that initially) but not in VB.NET.

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

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

```

that gets a compiler error but the C# version is ok.

Answer: 
I think code regions probably wouldn't be supported in method bodies since they, as you put it, would be a (somewhat) "ridiculous feature" - However, in C#, this **does** work, at least in VS 2008 and VS 2010 - just not in VB.NET.

That being said, I would avoid it. Putting regions within a method body would just leads to people making larger methods (since that's the only time when it would be worthwhile), which is something that should be avoided, not encouraged.

If your code:

> 
> defies simple refactoring such as method extraction
> 
> 
> 

I would focus, instead, on doing "complex" refactoring (or whatever it takes) to try to break up those methods. There is no way your "four or five hundred lines" long methods are at all maintainable in their current state.

Personally, I would leave them causing "pain" - make it obvious that they need work, right front and center, until you can break them up and refactor out portions.
*Visual Studio 2003* had them for VB.NET, but feature was removed in *Visual Studio 2005* and later. Really annoying when refactoring large procedures, yet you can split the code window.

Honestly, I wish C# would restrict region use because they are overly used. I have a macro that strips them out of all code files when inheriting C# projects.

Another feature removed was the list of overridable methods in the *Navigation Bar*. I check to see if they re-added this feature for every new version of *Visual Studio* since 2005.