StyleCop SA1124 DoNotUseRegions es razonable?

Question

SA1124 DoNotUseRegions sugieren que la región no se debe usar en ningún lado. ¿Es realmente razonable?

Creo que la región es una forma de agrupar códigos relativos y hacer que la clase grande sea fácil de leer; por ejemplo, si genera un método de interfaz para una clase en el contexto del menú contextual, se insertará automáticamente una región.

Me gustaría eliminar esta regla al verificar el estilo del código. ¿Puedo saber sus opiniones sobre esta regla?

Answer 1

Esto va a ser una cuestión de preferencia personal. Lo único que importa aquí es lo que usted y su equipo prefieren. Olvídese de lo que dice el policía de estilo, usted es el que lo lee, usted lo está manteniendo, ya sea con o sin regiones que funcione mejor para usted, eso es todo lo que importa.

Si lo está lanzando como un proyecto de código abierto ... y esta es mi opinión aquí, creo que se aplica lo mismo. Use lo que sea que el equipo central se sienta más cómodo. Si obtiene muchos más miembros del equipo a bordo y más contribuye, vuelva a visitar el tema más adelante, esto siempre se puede cambiar.

Answer 2

Creo que se pueden abusar de las regiones, pero son una técnica útil para permitir que un lector se centre en ciertas áreas del código a la vez.

Sin embargo, evitaría demasiados niveles de anidamiento.

Answer 3

Me pregunto si esta regla es un efecto secundario de otras reglas más generalmente aceptadas, como el pedido de miembros privados/protegidos/públicos. Seguir estas reglas de orden necesariamente rompería la agrupación lógica de # regiones en muchos casos, por lo que se volverían mutuamente excluyentes.

Answer 4

No hay más necesidad de regiones en un código bien escrito. Una vez fue útil para ocultar el código generado por la máquina. Ahora ese código va en un archivo separado. Las regiones todavía se pueden usar para ocultar código mal escrito.

Answer 5

En mi opinión hay una excepción donde un # region/# endregion tiene sentido: ¡Al implementar interfaces!

p. Ej.

#region Implementation of IDisposable 
public void Dispose() 
{ 
    // implementation here ... 
} 
#endregion 

En todos los demás casos no se debe utilizar #region ya que son obsoletos (supongo que el dónde creó para ocultar código generado - .NET 1.0 y .NET 1.1, pero ahora hay clases parciales para que)

--Harald-René Flasch (también conocido como hfrmobile)

Answer 6

me gusta regiones y mi equipo y me siento código es más legible con ellos.

Éstos son los momentos en los que los amo ...

Si usted tiene un estándar de la compañía para escribir pruebas unitarias con arreglos Ley Assert (AAA), entonces podría requerir pruebas de unidad para buscar la siguiente manera

[test] 
public void MyFunction_Test 
{ 
#region Arrange 
#endregion  

#region Act 
#endregion 

#region Assert 
#endregion 
} 

Me gusta mucho este formato especialmente cuando hay separaciones claras y hacerlo inspira a otros a hacer algo correctamente, como escribir pruebas de unidad correctamente.

El otro lugar que me gusta de la región es el código cuando sabe que va a eliminar el código pronto.

#region Drop this region next version when we drop 2003 support 
public void DoSomeThingWithWindowsServer2003() 
{ 
    // code the is for Windows 2003 only 
} 
#endregion 

También uso regiones para separar las diferentes partes de mis clases, incluso si la clase es muy pequeña.

#region Constructors 
#endregion 

#region Properties 
#endregion 

#region Events 
#endregion 

#region Methods 
#endregion 

#region Enums 
#endregion 

Por lo general, una clase no tendrán todos ellos (si es que usted puede preguntarse si se está haciendo demasiado en una sola clase) pero creo que si usted está buscando un único método o propiedad, Es bueno tener un solo lugar para mirar. Por no mencionar una propiedad en un modelo de vista (MVVM ¿alguien?) Utilizando INotifyPropertyChanged es de 10 líneas (9 líneas más un espacio), así que el objeto ViewModel bien diseñado y bien escrito con solo 5 propiedades, significa que la sección de propiedades es de al menos 50 líneas de código.

También me gustan especialmente cuando uso el código mal escrito de otra persona. Es una tontería asumir que siempre puedes refactorizar para usar un diseño perfecto. Por ejemplo, tienes una clase con 2500 líneas o más. Claro que esto probablemente podría haberse escrito mejor, pero no lo hizo, funciona, y está probado, y su empresa tiene el código en el bloqueo "solo de reparación", por lo que no se permite refactorizar. Puede hacer que una clase demasiado grande (mal escrita o no) sea mucho más legible usando declaraciones #region. Obtienes muchos de los beneficios de legibilidad de la separación de preocupaciones sin separar realmente la clase y luego, una vez que el código sale del bloqueo y puedes refactorizar, la mayoría del trabajo de separación ya puede hacerse utilizando # regiones y puedes convertir tu regiones en clase separada.

Answer 7

Según mi experiencia, no deberían usarse en absoluto. Los desarrolladores menores tienden a abusar de ellos y crean clases demasiado complejas cuya complejidad se esconde "inteligentemente" detrás de numerosas regiones.