c# - sirve - Orden de los elementos en las clases: Campos, Propiedades, Constructores, Métodos
propiedades de una clase c# (15)
Ciertamente no hay nada en el lenguaje que lo haga cumplir de ninguna manera. Tiendo a agrupar las cosas por visibilidad (pública, luego protegida, luego privada) y uso #regions para agrupar las cosas relacionadas funcionalmente, independientemente de si es una propiedad, un método o lo que sea. Los métodos de construcción (ya sean los controladores reales o las funciones de fábrica estáticas) suelen estar en la parte superior, ya que son lo primero que los clientes necesitan saber.
¿Existe una guía oficial de C # para el orden de los artículos en términos de estructura de clase?
Se 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 todo el lugar. Quiero seguir un estándar particular para poder hacerlo en cualquier lugar.
El problema real es que mis propiedades más complejas terminan pareciéndose a los métodos y se sienten fuera de lugar en la parte superior antes que el constructor.
¿Algún consejo / sugerencia?
Como se mencionó anteriormente, no hay nada en el lenguaje C # que dicte el diseño, yo personalmente uso regiones y hago algo como esto 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 forma parte del proceso de compilación de MS, puede verlo como un estándar de facto.
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
- Enums
- Interfaces
- Propiedades
- Indexadores
- Métodos
- Estructuras
- Las clases
Dentro de cada uno de estos grupos ordena por acceso: (SA1202)
- público
- interno
- protegido interno
- protegido
- privado
Dentro de cada uno de los grupos de acceso, ordene 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 por solo lectura, luego no solo lectura: (SA1214 y SA1215)
- solo lectura
- no solo de 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 múltiples interfaces y los métodos y las propiedades de la interfaz se deben agrupar), luego use una clase parcial para agrupar los métodos y las propiedades relacionados.
En lugar de agrupar por visibilidad o por tipo de elemento (campo, propiedad, método, etc.), ¿qué hay de 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 que casi invariablemente voy a cazar a 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 muy positivo psicológicamente. La recomendación estándar de poner constructores después de un montón de otras cosas se siente disonante.
La próxima característica del constructor primario en C # 6 proporciona evidencia de que el lugar natural para un constructor se encuentra en la parte superior de una clase; de hecho, los constructores primarios se especifican incluso antes de la llave abierta.
Es gracioso la diferencia que hace un reordenamiento como este. Me recuerda cómo se solían ordenar las declaraciones, con los espacios de nombres del sistema primero. El comando "Organizar Usos" de Visual Studio usó este orden. Ahora, el using s está ordenado alfabéticamente, sin tratamiento especial para los espacios de nombres del sistema. El resultado se siente más simple y limpio.
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 constructores al lado.
mi comentario general sería que debería atenerse a una clase por archivo y si la clase es lo suficientemente grande como para que la organización de las propiedades frente a los métodos sea una gran preocupación, ¿qué tan grande es la clase y debería refactorizarla de todos modos? ¿Representa múltiples preocupaciones?
Lo más cercano que es probable que encuentres es "Directrices de diseño, código administrado y .NET Framework" ( http://blogs.msdn.com/brada/articles/361363.aspx ) por Brad Abrams
Muchas normas se describen aquí. La sección relevante es 2.8 creo.
Lo mantengo lo más simple posible (al menos para mí)
Enumeraciones
Declaraciones
Constructores
Anulaciones
Métodos
Propiedades
Controlador de eventos
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 a Style Cop y si alguien me puede dar una buena razón por la que debo colocar los detalles de la implementación de un tipo antes de su interfaz, estoy dispuesto a cambiar. En la actualidad, tengo una fuerte preferencia por poner a los miembros privados en último lugar.
Nota: No uso campos públicos o protegidos.
No conozco un idioma o un estándar de la industria, pero tiendo a poner las cosas en este orden con cada sección envuelta en un #region:
utilizando declaraciones
Espacio de nombres
Clase
Miembros privados
Propiedades publicas
Constructores
Métodos públicos
Metodos privados
Prefiero colocar los campos privados en la parte superior junto con el (los) constructor (es), luego colocar 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 orden de los artículos sea muy importante, es probable que sea un olor de código que indique que su clase es demasiado voluminosa y compleja y que debe refactorizarla.
Recomendaría utilizar los estándares de codificación de IDesign o los que se enumeran en el sitio web de Brad Abram . Esos son los dos mejores que he encontrado.
Brad diría ...
Los miembros de las clases deben estar ordenados alfabéticamente y agrupados en secciones (Campos, Constructores, Propiedades, Eventos, Métodos, Implementaciones de interfaz privada, Tipos anidados)
Sé que esto es viejo pero mi orden es la siguiente:
En orden 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 método 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; }
}
Usualmente trato de seguir el siguiente patrón:
- miembros estáticos (normalmente tienen otro contexto, deben ser seguros para subprocesos, etc.)
- miembros de instancia
Cada parte (estática y instancia) consta de los siguientes tipos de miembros:
- Operadores (son siempre estáticos)
- campos (inicializados antes de constructores)
- constructores
- destructor ( es una tradición seguir a los constructores )
- propiedades
- metodos
- eventos
Luego, los miembros se ordenan por visibilidad (de menos a más visible):
- privado
- interno
- protegido interno
- 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 del contexto.