Orden de elementos en clases: campos, propiedades, constructores, métodos

¿Existe una directriz oficial de C # para el orden de los elementos en términos de estructura de clases?

Va:

• Campos publicos
• Campos privados
• Propiedades
• Constructores
• Métodos
  ?

Tengo curiosidad por saber si hay una regla estricta y rápida sobre el orden de los artículos. Estoy un poco por todas partes. Quiero seguir un estándar particular para poder hacerlo en todas partes.

El verdadero problema es que mis propiedades más complejas terminan pareciéndose mucho a los métodos y se sienten fuera de lugar en la parte superior antes del constructor.

¿Algún consejo / sugerencia?

De acuerdo con la documentación de las reglas de StyleCop, el orden es el siguiente.

Dentro de una clase, estructura o interfaz: (SA1201 y SA1203)

• Campos constantes
• Campos
• Constructores
• Finalizadores (Destructores)
• Delegados
• Eventos
• Enumeraciones
• Interfaces ( implementaciones de interfaz )
• Propiedades
• Indexadores
• Métodos
• Estructuras
• Clases

Dentro de cada uno de estos grupos ordenar por acceso: (SA1202)

• público
• interno
• interno protegido
• protegido
• privado

Dentro de cada uno de los grupos de acceso, ordenar por estático, luego no estático: (SA1204)

• estático
• no estático

Dentro de cada uno de los grupos de campos estáticos / no estáticos, ordene solo lectura, luego no solo lectura: (SA1214 y SA1215)

• solo lectura
• no solo lectura

Una lista desenrollada tiene 130 líneas de largo, así que no la desenrollaré aquí. La parte de métodos desenrollada es:

• métodos estáticos públicos
• métodos públicos
• métodos estáticos internos
• métodos internos
• métodos estáticos internos protegidos
• métodos internos protegidos
• métodos estáticos protegidos
• métodos protegidos
• métodos estáticos privados
• métodos privados

La documentación señala que si el orden prescrito no es adecuado, por ejemplo, se están implementando varias interfaces y los métodos y propiedades de la interfaz se deben agrupar, use una clase parcial para agrupar los métodos y propiedades relacionados.

En lugar de agrupar por visibilidad o por tipo de elemento (campo, propiedad, método, etc.), ¿qué tal agrupar por funcionalidad?

Esta es una pregunta antigua pero aún muy relevante, así que agregaré esto: ¿Qué es lo primero que busca cuando abre un archivo de clase que puede o no haber leído antes? ¿Campos? Propiedades? Me he dado cuenta por experiencia de que casi siempre voy en busca de los constructores, porque lo más básico para entender es cómo se construye este objeto.

Por lo tanto, comencé a poner a los constructores primero en los archivos de clase, y el resultado ha sido psicológicamente muy positivo. La recomendación estándar de colocar a los constructores después de un montón de otras cosas se siente disonante.

La próxima característica de constructor primario en C # 6 proporciona evidencia de que el lugar natural para un constructor está en la parte superior de una clase; de ​​hecho, los constructores primarios se especifican incluso antes del paréntesis abierto.

Es curioso la diferencia que hace un reordenamiento como este. Me recuerda cómo usingsolían ordenarse las declaraciones, primero con los espacios de nombres del Sistema. El comando "Organizar usos" de Visual Studio utilizó este orden. Ahora los usings se ordenan alfabéticamente, sin un tratamiento especial para los espacios de nombres del Sistema. El resultado simplemente se siente más simple y limpio.

No sé acerca de un idioma o estándar de la industria, pero tiendo a poner las cosas en este orden con cada sección envuelta en una # región:

utilizando declaraciones

Espacio de nombres

Clase

Miembros privados

Propiedades publicas

Constructores

Métodos públicos

Métodos privados

Recomendaría usar los estándares de codificación de IDesign o los que figuran en el sitio web de Brad Abram . Esos son los dos mejores que he encontrado.

Brad diría ...

El miembro de las clases se debe ordenar alfabéticamente y agrupar en secciones (campos, constructores, propiedades, eventos, métodos, implementaciones de interfaz privada, tipos anidados)

Como se mencionó anteriormente, no hay nada en el lenguaje C # que dicte el diseño, yo personalmente uso regiones, y hago algo así para una clase promedio.

public class myClass
{
#region Private Members

#endregion
#region Public Properties

#endregion

#region Constructors

#endregion
#region Public Methods

#endregion
}

Tiene sentido para mí de todos modos

De StyleCop

campos privados, campos públicos, constructores, propiedades, métodos públicos, métodos privados.

Como StyleCop es parte del proceso de compilación de MS, puede verlo como un estándar de facto

Por lo general, trato de seguir el siguiente patrón:

• miembros estáticos (generalmente tienen otro contexto, deben ser seguros para subprocesos, etc.)
• miembros de instancia

Cada parte (estática e instancia) consta de los siguientes tipos de miembros:

• operadores (son siempre estáticos)
• campos (inicializados antes de los constructores)
• constructores
• destructor ( es una tradición seguir a los constructores )
• propiedades
• métodos
• eventos

Luego, los miembros se ordenan por visibilidad (de menos a más visible):

• privado
• interno
• interno protegido
• protegido
• público

El orden no es un dogma: las clases simples son más fáciles de leer, sin embargo, las clases más complejas necesitan agrupación específica de contexto.

Mi preferencia es ordenar por tipo y luego disminuir la visibilidad de la siguiente manera

public methods
public events
public properties

protected methods
protected events
protected properties

private methods
private events
private properties
private fields

public delegates
public interfaces
public classes
public structs

protected delegates
protected interfaces
protected classes
protected structs

private delegates
private interfaces
private classes
private structs

Sé que esto viola Style Cop y si alguien me puede dar una buena razón por la que debería colocar los detalles de implementación de un tipo antes de su interfaz, estoy dispuesto a cambiar. En la actualidad, tengo una gran preferencia por poner a los miembros privados en último lugar.

Nota: no utilizo campos públicos o protegidos.

Lo más probable es que encuentre "Pautas de diseño, código administrado y .NET Framework" ( http://blogs.msdn.com/brada/articles/361363.aspx ) por Brad Abrams

Muchos estándares se describen aquí. La sección relevante es 2.8, creo.

Las únicas pautas de codificación que he visto sugeridas para esto es colocar los campos en la parte superior de la definición de clase.

tiendo a poner a los constructores a continuación.

mi comentario general sería que debería apegarse a una clase por archivo y si la clase es lo suficientemente grande como para que la organización de propiedades versus métodos sea una gran preocupación, ¿qué tan grande es la clase y debería refactorizarla de todos modos? ¿representa múltiples preocupaciones?

Prefiero poner los campos privados en la parte superior junto con los constructores, luego poner los bits de la interfaz pública después de eso, luego los bits de la interfaz privada.

Además, si la definición de su clase es lo suficientemente larga como para que el pedido de artículos sea importante, es probable que sea un olor a código que indique que su clase es demasiado voluminosa y compleja y que debe refactorizar.

Lo mantengo lo más simple posible (al menos para mí)

Enumeraciones
Declaraciones
Constructores
Invalida
Métodos
Propiedades
Controlador de eventos

Ciertamente, no hay nada en el lenguaje que lo imponga de ninguna manera. Tiendo a agrupar cosas por visibilidad (pública, luego protegida, luego privada) y uso #regiones para agrupar funcionalmente cosas relacionadas, independientemente de si es una propiedad, método o lo que sea. Los métodos de construcción (ya sean procesadores reales o funciones de fábrica estáticas) generalmente están en la parte superior, ya que son lo primero que los clientes deben saber.

Sé que esto es viejo pero mi orden es la siguiente:

en orden de público, protegido, privado, interno, abstracto

• Constantes
• Variables Estáticas
• Campos
• Eventos
• Constructor (es)
• Métodos
• Propiedades
• Delegados

También me gusta escribir propiedades como esta (en lugar del enfoque abreviado)

// Some where in the fields section
private int someVariable;

// I also refrain from
// declaring variables outside of the constructor

// and some where in the properties section I do
public int SomeVariable
{
    get { return someVariable; }
    set { someVariable = value; }
}