it-swarm-es.com

¿Cómo distribuye 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

Fields siendo Propiedades Privadas y Properties siendo 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).

17
Rachel

Subregiones? ¿Tu clase tiene una Responsabilidad única ? (implícito en eso ... mi respuesta es "Rara vez cualquier región, excepto quizás para agrupar propiedades, constructores y métodos" ... pero incluso entonces, no lo uso tanto)

17
MIA

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

Me sorprende que nadie haya mencionado evitar el uso de regiones. Entiendo que el OP quiere realizar una encuesta sobre la distribución de regiones, pero me gustaría plantear un punto de vista alternativo.

Evito 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 clases similares.

¿Por qué odio las regiones? CTRL+M,LCTRL+M,O alternará el plegado del código. Sin embargo, al colapsar oculta toda la región. Solo necesito contraer 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 proporciona una buena publicación sobre regiones que vale la pena leer.

Mi cita favorita sobre #regiones:

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é en ofrecer una alternativa.

10
snmcdonald

Varía de un idioma a otro. Como soy un 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.

4
Mason Wheeler

Tiendo a distribuirlos de la siguiente manera:

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

No he usado un lenguaje que use Properties, por eso no están establecidos. Pongo los 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 la cosa pública. Y todos los editores de texto que conozco, e incluso los IDE, colocan el cursor en la parte superior al abrir archivos.

3
gablin

El libro Código limpio de Bob Martin dedica todo el quinto capítulo al formato. Hay un par de puntos clave que creo resumir muy bien.

  • La mayoría de los intentos de agrupar variables y métodos por visibilidad y limpieza no tienen mucho sentido y hacen que navegue mucho por el código.
  • Mantener los métodos que se llaman entre sí verticalmente 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 "¿a qué región pertenece este fragmento de código?" cada pocos minutos.
  • Las variables de instancia generalmente deben ser pocas y es probable que 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 usan solo con un par de métodos, entonces deben estar verticalmente cerca pero por encima de los pocos métodos que los usan.

Mantener su código organizado con elementos que interactúan comúnmente verticalmente juntos elimina efectivamente cualquier necesidad de crear regiones específicas. Si su código es tan largo que requiere que las regiones oculten una gran cantidad de código, entonces tal vez sea un olor a código que indique que la clase está tratando de hacer demasiado. Quizás algunas de las funciones se puedan trasladar a una clase de utilidad o aumentar a un antepasado.

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

2
S.Robins

Es una llamada de juicio para mí. Utilizo regiones cuando se necesitan para facilitar la lectura.

También utilizo un color diferente en mi esquema de color 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.

2
Robert Harvey

Al igual que Wyatt y un par de otras respuestas, generalmente también evito el uso de regiones. Las regiones tienen un propósito; para ocultar el código que no desea tener que mirar. Si tiene mucho código en una clase que no quiere 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 las implementaciones de interfaz).

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

  • Ciertas implementaciones de interfaz integradas (IDisposable, IConvertible, a veces IEnumerable o IComparable, ya que requieren implementaciones genéricas y no genéricas)
  • Externos P/Invoke integrados y estructuras relacionadas.
  • Finalizadores/destructores (generalmente va con IDisposable)
  • Se engancha a memoria no administrada/punteros/código "inseguro".
0
KeithS

Respuesta marginal lunática: 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 estas cosas; simplemente comience a escribir donde está el cursor.

0
Wyatt Barnett