¿Cómo diseñas normalmente las regiones de una clase?

Me preguntaba si había un estándar para diseñar las regiones de una clase.

Actualmente uso

Fields
Constructor
Properties
Public Methods
Private Methods

Fieldssiendo propiedades privadas y Propertiessiendo las públicas. Normalmente usaré subregiones dentro de eso si es necesario, o ocasionalmente agregaré otras regiones a continuación (como la interfaz o los miembros de baseClass).

Enumeraciones relacionadas con la clase u ocasionalmente estructuras / clases de datos puros (por encima de la definición de clase real)

--- Definición de clase ---

Miembros privados

CTOR / DTOR si el idioma tiene DTOR

Propiedades publicas

Métodos de utilidad (métodos privados o protegidos con pequeño alcance)

Funcionalidad de clase (puede dividirse en varias regiones según el alcance de la clase).

Sub Regiones? ¿Tu clase tiene una responsabilidad única ? (implícito en eso ... mi respuesta es "Raramente cualquier región, excepto tal vez para agrupar propiedades, constructores y métodos" ... pero aun así, no lo uso tanto)

Solo quería confirmar que se refería a "#regiones" y no al diseño de clase en general.

Me sorprende que nadie haya mencionado para evitar el uso de regiones. Entiendo que el OP quiere realizar una encuesta sobre el diseño de las regiones, pero me gustaría plantear un punto de vista alternativo.

Evito las regiones. Me gusta ver el código con el que estoy trabajando. Si le resulta difícil encontrar lo que está buscando, utilice el plegado de código y agrupe construcciones de clase similares.

¿Por qué odio las regiones? CTRL+M,Ly CTRL+M,Oalternará el código de plegado. Sin embargo, al colapsar, oculta toda la región. Solo necesito colapsar métodos / propiedades / comentarios.

Si hay demasiadas regiones, tal vez sea un olor a código y su clase está haciendo demasiado trabajo. Jeff Atwood ofrece una buena publicación sobre regiones que vale la pena leer.

Mi cita favorita en #regions:

No, no usaré #regions. Y no, NO NEGOCIO CON TERRORISTAS. Cállate.

- Jeff Atwood

Dicho esto, sé que muchos programadores insisten en usarlos. Esta pregunta es subjetiva. Solo pensé que ofrecería una alternativa.

Varía de un idioma a otro. Como soy codificador de Delphi, tiendo a seguir la convención estándar de Delphi, que se ve así:

type
  TMyClass = class(TBaseClass)
  private
    private fields
    private methods
  protected
    protected fields
    protected methods
    protected properties
  public
    constructor(s)
    destructor
    public methods
    public properties
  end;

Me parece una buena forma de organizar la información que es fácil de leer y comprender.

Tiendo a exponerlos de la siguiente manera:

Public fields (usually static constants)
Constructors
Public methods
Private methods
Private fields

No he usado un lenguaje que lo use, Propertiespor eso no se presentan. Puse métodos y campos privados en la parte inferior porque si alguien más está usando este archivo en su código, solo deberían preocuparse por la API, que es lo público. Y todos los editores de texto que conozco, e incluso los IDE, colocan el cursor en la parte superior al abrir archivos.

Es una decisión judicial para mí. Uso regiones cuando son necesarias para facilitar la lectura.

También uso un color diferente en mi combinación de colores de Visual Studio (actualmente un rojo oscuro) para que se destaquen del resto del código.

Un ejemplo de dónde podría usar una # región: si escribo un método de prueba para una prueba unitaria que requiere un fragmento de XML de varias líneas, la cadena XML romperá la sangría habitual (ya que comienza a lo largo del margen izquierdo de la ventana de código. Para ocultar la fealdad, la envolveré en una # región, para poder colapsarla.

El libro Clean Code de Bob Martin dedica todo el quinto capítulo al formateo. Hay un par de puntos clave que creo que lo resumen muy bien.

• La mayoría de los intentos de agrupar variables y métodos por visibilidad y limpieza no tiene mucho sentido y hace que navegue mucho por el código.
• Mantener métodos que se llaman verticalmente entre sí reduce la cantidad de navegación que necesita hacer y facilita la búsqueda de cosas.
• Su línea de pensamiento no se romperá si tiene que detenerse y pensar "¿en qué región pertenece este código?" cada pocos minutos.
• Las variables de instancia generalmente deben ser pocas, y probablemente se usen en todas partes, por lo tanto, pertenecen a la parte superior de la clase donde serán más fáciles de ubicar. Las variables y declaraciones que solo serán utilizadas por un método deben existir dentro de ese método. Si se usa solo con un par de métodos, entonces deben estar verticalmente cerca pero por encima de los pocos métodos que los están usando.

Mantener su código organizado con elementos que interactúan comúnmente verticalmente juntos de manera efectiva elimina cualquier necesidad de crear regiones específicas. Si su código es tan largo que requiere que las regiones oculten mucho código, entonces quizás sea un olor a código que indica que la clase está tratando de hacer demasiado. Quizás parte de la funcionalidad se pueda trasladar a una clase de utilidad o subir a un antepasado.

Si necesita "ocultar" el código porque es demasiado largo o demasiado "feo", entonces probablemente tenga mayores problemas de los que preocuparse que si usar o no las regiones. Personalmente, nunca necesito usarlos, y cuando trabajo en el código de otra persona, siempre necesito abrirlos todos, así que ¿por qué molestarse?

Actualmente diseño clases como esta:

class types
constructors
destructor
accessors
methods
properties (where properties are present in the language)
member variables

y luego prefije el nivel de acceso a cada declaración (más o menos, a veces agrupar por acceso). Solía ​​agrupar a nivel superior por acceso, pero en algún momento, no sé cuándo, no funcionó tan bien como lo anterior. Por ejemplo, en C ++ / CLI (que estoy obligado a usar en este momento :-() puede hacer esto, lo que desordena la agrupación por acceso:

public: property int SomeProperty
{
private: void set (int value) { ... }
public: int get () { ... }
}

Respuesta marginal: no, al menos cuando se trata de C #. Entre Visual Studio y R # puedo navegar mágicamente a cualquier miembro o implementación, por lo que no tiene sentido obsesionarse con esto; simplemente comienza a escribir donde está el cursor.

Al igual que Wyatt y otras respuestas, generalmente también evito el uso de regiones. Las regiones tienen un propósito; para ocultar el código que no quieres tener que mirar. Si tiene mucho código en una clase que no desea tener que mirar y, por lo tanto, necesita muchas regiones que le permitan colapsar dicho código, entonces probablemente tenga demasiado código en la clase. ReSharper no respeta las regiones al decidir dónde colocar el nuevo código, a menos que haya creado la región (lo que hace para implementaciones de interfaz).

El único uso de las regiones que considero aceptable es ocultar el código "inevitablemente feo"; código que trata con detalles de implementación específicos que no pueden ser bien diseñados internamente según los estándares actuales. Por lo general, este es un código esotérico avanzado que, en general, no debe ser molestado por el programador junior promedio una vez escrito. Estas son cosas como:

• Ciertas implementaciones de interfaz incorporadas (IDisposable, IConvertible, a veces IEnumerable o IComparable, ya que requieren implementaciones genéricas y no genéricas)
• Incrustado P / Invocar externos y estructuras relacionadas.
• Finalizadores / destructores (generalmente va con IDisposable)
• Se conecta a la memoria no administrada / punteros / código "inseguro".