example - region inside region c#

¿Regiones de código no permitidas dentro de cuerpos de método en VB.NET?

Question

Nota : Esta "función" ahora se ha agregado a Visual Studio 2015, pero la pregunta durará un tiempo, ya que no todos los desarrolladores ni todas las tiendas de desarrollo obtienen acceso al IDE más reciente y excelente tan pronto como se publica.

PREGUNTA ORIGINAL:

Normalmente no "necesitaría" ni siquiera consideraría una característica ridícula como las regiones de código dentro de los cuerpos de métodos pero: estoy refactorizando el código VB.NET donde los métodos rutinariamente ejecutan quinientas líneas de código o más y las referencias están tan estrechamente unidas que el código desafía la refactorización simple como la extracción de métodos.

Y es por eso que pensé que probaría las regiones dentro de un cuerpo de método. Solo quería organizar el código a corto plazo. Pero el IDE no me deja (resultó en un error de compilación). ¿Tengo curiosidad de por qué? Parece que las regiones de código no deberían afectar al compilador, intellisense, etc. ¿Me estoy perdiendo algo? (Aún usando VS 2005 por cierto)

Interesante: Esto parece ser específico del idioma. Está bien en C # (no lo revisé inicialmente) pero no en VB.NET.

public module MyModule
Sub RunSnippet()
dim a as A = new A (Int32.MaxValue )
#region
Console.WriteLine ("")
#end region
....

eso obtiene un error de compilación, pero la versión de C # está bien.

Answer 1

A partir de noviembre de 2015: en Visual Studio 2015 ahora es compatible, solo haz lo que quieras.

Código de muestra:

With frmMain
#region "A sample region in odd place"
.show()
.text = "Sample"
#end region
End With

Nota: en versiones anteriores de Visual Studio parece que no está funcionando en VB.NET, pero en C # está funcionando.

Answer 2

Creo que las regiones de código probablemente no serían compatibles con los cuerpos de métodos ya que, como usted dice, sería una (algo) "característica ridícula". Sin embargo, en C #, esto funciona, al menos en VS 2008 y VS 2010 - simplemente no en VB.NET.

Dicho eso, lo evitaría. Situar las regiones dentro de un cuerpo de método solo llevaría a las personas a hacer métodos más grandes (ya que es el único momento en el que valdría la pena), que es algo que debe evitarse, no alentarse.

Si tu código:

desafía la refactorización simple como la extracción de métodos

Me centraría, en cambio, en refactorizar "complejo" (o lo que sea necesario) para tratar de romper esos métodos. No hay forma de que sus métodos largos de "cuatro o quinientas líneas" sean mantenibles en su estado actual.

Personalmente, los dejaría causando "dolor", es obvio que necesitan trabajo, justo al frente y al centro, hasta que los dividan y refaccionen las porciones.

Answer 3

Es explícito en el capítulo 3.3 de la especificación del lenguaje de Visual Basic 9.0:

Las directivas de región agrupan líneas de código fuente pero no tienen otro efecto en la compilación. Todo el grupo puede colapsarse y ocultarse, o expandirse y verse, en el entorno de desarrollo integrado (IDE). Estas directivas son especiales porque no pueden comenzar ni terminar dentro de un cuerpo de método

O en otras palabras: no puede hacerlo porque la especificación lo dice.

En cuanto a por qué se especificó así, creo que tiene algo que ver con la antigua función IDE que VB ha tenido durante el tiempo que puedo recordar: Herramientas + Opciones, Editor de texto, Básico, VB específico, Mostrar línea de procedimiento separadores. Es solo una suposición, probablemente no muy buena.

Actualización: ahora compatible con Roslyn, incluido primero con VS2015.

Answer 4

Esta fue simplemente una elección del equipo de VB al agregar la función de regiones a la versión 7 del lenguaje de Visual Basic. Se consideró como una característica que era útil para organizar a nivel de declaración y no dentro de un método y, por lo tanto, solo se permitía en ese nivel.

El equipo de C # sintió de manera diferente esta característica y la permitió en muchos otros lugares. Siempre me ha sorprendido que las directivas de C # #region puedan ocurrir en diferentes contextos de declaración.

#region Foo
class Bar {
#endregion
}

El código equivalente no está permitido en VB.

Answer 5

No sé acerca de VB, pero en C # esto está permitido desde 1.0 hasta donde sé.

De hecho, incluso puede poner regiones de código en lugares impares que cruzan ámbitos. Por ejemplo:

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

Aquí la región comienza dentro de la declaración if , pero termina fuera de ella. Horrible, pero el compilador está de acuerdo.

¿A qué te refieres cuando dijiste que el IDE no "dejaba" poner código en regiones? ¿Recibió un error de compilación?

Answer 6

Otro método alternativo simple:

Lo que puedes hacer es básicamente seleccionar el código al que deseas agregar la #Region #End Region y básicamente hacer clic en:

Ctrl + M , Ctrl + H

Esto básicamente envuelve el código. Y luego, para hacerlo aún más ordenado y fácil de encontrar, puedes comentar el código. El resultado final se vería así:

Answer 7

Para cualquiera que busque la respuesta más reciente a esta pregunta, ahora es posible en VB.NET (a partir de la versión 14 ).

Directivas de la región dentro de los cuerpos del método

Puede poner # Region ... # Fin delimitadores de región en cualquier lugar de un archivo, dentro de funciones e incluso abarcando cuerpos de funciones.

El ejemplo de OP ahora es una sintaxis perfectamente legal:

Sub RunSnippet()
Dim a as A = New A (Int32.MaxValue )
#Region "Test"
Console.WriteLine ("")
#End Region
End Sub

Answer 8

Visual Studio 2003 los tenía para VB.NET, pero la función se eliminó en Visual Studio 2005 y versiones posteriores. Realmente molesto al refaccionar procedimientos grandes, sin embargo, puede dividir la ventana de código.

Honestamente, me gustaría que C # restrinja el uso de la región porque son demasiado utilizados. Tengo una macro que los quita de todos los archivos de código al heredar proyectos de C #.

Otra característica eliminada fue la lista de métodos invalidables en la barra de navegación . Reviso para ver si volvieron a agregar esta característica para cada nueva versión de Visual Studio desde 2005.