c# - studio - stylecop tutorial

StyleCop SA1124 DoNotUseRegions es razonable? (7)

Creo que las regiones pueden ser objeto de abuso, 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 anidación.

SA1124 DoNotUseRegions sugiere que la región no debe usarse en ningún lugar. ¿Es realmente razonable?

Creo que la región es una forma de agrupar código relativo y hacer que la clase grande sea fácil de leer, por ejemplo, si genera un método de interfaz para una clase en vs2008 a través del menú contextual, se insertará una región automáticamente.

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

Desde mi experiencia no deberían ser utilizados en absoluto. Los desarrolladores junior tienden a abusar de ellos y crean clases demasiado complejas cuya complejidad está "inteligentemente" oculta detrás de numerosas regiones.

En mi opinión, hay una excepción en la que tiene sentido # region / # endregion: ¡Al implementar Interfaces!

p.ej

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

En todos los demás casos, no debe usar #region ya que están obsoletos (supongo que donde se creó para ocultar el código generado: .net-1.0 y .net-1.1, pero ahora hay clases parciales para eso)

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

Esto va a ser una cosa de preferencia personal. Lo único que importa aquí es lo que tú y tu equipo prefieren . Olvídese del estilo que dice el policía, usted es quien lo lee, el que lo mantiene, ya sea que con o sin regiones funcione mejor para usted, eso es 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. Usa lo que sea más cómodo para el equipo central. Si recibe más miembros del equipo a bordo y más contribuye, vuelva a visitar el problema más adelante, esto siempre se puede cambiar.

Me gustan las regiones y mi equipo y siento que el código es más legible con ellas.

Aquí están los momentos en que los amo ...

Si tiene un estándar de la compañía para escribir pruebas unitarias con Arrange Act Assert (AAA), entonces puede requerir que las pruebas unitarias tengan el siguiente aspecto:

[test] public void MyFunction_Test { #region Arrange #endregion #region Act #endregion #region Assert #endregion }

Realmente me gusta este formato, especialmente cuando hay separaciones claras y hacerlo inspira a otros a hacer algo correctamente, como escribir las pruebas unitarias correctamente.

El otro lugar en el que me gusta la región es el código es cuando sabes que vas 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 utilizo 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á todo esto (si es así, quizás se pregunte si está haciendo demasiado en una sola clase), pero creo que si está buscando un método o una propiedad individual, es bueno tener un solo lugar. mirar. Sin mencionar que una propiedad en un ViewModel (¿MVVM?) Usando INotifyPropertyChanged es de 10 líneas (9 líneas más un espacio), por lo que el objeto ViewModel está 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 codigo

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

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

No hay más necesidad de regiones en código bien escrito. Una vez fue útil 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.