generate - params comments c#

¿Cuál es la mejor manera de diseñar una clase C#?

Question

Esta pregunta ya tiene una respuesta aquí:

• Orden de los artículos en las clases: Campos, Propiedades, Constructores, Métodos 15 respuestas

¿Hay una forma estándar de diseñar un archivo C #? Como en, Campos, luego Propiedades, luego Constructores, etc.

Esto es lo que normalmente hago, ¿pero me pregunto si hay una forma estándar?

1. Clases anidadas o Enumerados
2. Campos
3. Propiedades
4. Eventos
5. Constructores
6. Métodos públicos
7. Métodos privados

¿Las personas agrupan sus campos juntos, o los ponen con las propiedades? ¿O la gente no se preocupa por un pedido? Visual Studio parece hacerlo tan difícil de hacer.

Editar : movió otra parte sobre ReSharper aquí: haga que Resharper respete su preferencia por el orden de los códigos.

Answer 1

Además de mantener un conjunto coherente de regiones en los archivos de clase, guardo todos los componentes de una región en orden alfabético. Tiendo a tener un poco de "memoria visual" cuando se trata de leer el código y me vuelve loco tener que usar el menú desplegable de navegación para encontrar el código en un archivo porque está por todos lados.

Answer 2

Cada uno por su cuenta, pero tiendo a seguir el mismo orden que sigue la ayuda de MSDN.

Tampoco me gusta anidar clases o enumeraciones, sino crear archivos separados para ellos, que también hacen que las pruebas de unidades de escritura sean más fáciles (ya que es fácil encontrar el archivo de prueba asociado cuando necesita agregar / corregir / refactorizar una prueba).

En mi humilde opinión, el orden no es tan importante porque VS hace que sea muy fácil encontrar todos los miembros (especialmente si sigues el enfoque de una clase / interfaz / enum por archivo), y Sandcastle los agrupará si quieres compilar documentos, así que '' estar más preocupado por darles nombres significativos.

Answer 3

Como dije, no creo que haya una mejor manera como tal. Pero alguna organización lo ayuda a usted al programador.

¿Con qué frecuencia en un proyecto largo pasó tiempo subiendo y bajando uno o más archivos fuente tratando de encontrar una de sus funciones?

Así que #region mucho la región #region en este tipo de camino:

1. Eventos de región : todas las referencias de eventos que utiliza esta clase (al menos en esta clase parcial particular).

2. Controles de región : todas las funciones que interactúan directamente con los controles en un formulario.

3. región MDI : configurar el mdi

   Entonces habrá algo que ver con la funcionalidad en lugar de la interfaz,

4. región Regex busca

De alguna manera lo inventé a medida que avanzaba, pero usando el mismo patrón que siempre uso. Debo decir que me han dicho algunos programadores que recogen mi trabajo que es fácil de seguir y otros que está desordenado.

Puedes complacer a la mitad de las personas la mitad del tiempo y la otra mitad un cuarto del tiempo y el otro cuarto del tiempo confundes a todos, incluyéndote a ti. Creo que Winston Chrchil dijo eso.

Answer 4

Creo que no hay la mejor manera. Hay dos cosas importantes a considerar cuando se trata de diseño. Lo primero y más importante es la consistencia. Elija un enfoque y asegúrese de que todo el equipo esté de acuerdo y aplique el diseño. En segundo lugar, si su clase es lo suficientemente grande como para buscar dónde viven esas propiedades molestas (o tienen que implementar regiones para que sean más fáciles de encontrar), entonces su clase probablemente sea demasiado grande. Considere olfatearlo y refactorizar según lo que huele.

Para responder a la pregunta de readaptación, verifique en Configuración de miembros de tipo en Opciones (en el nodo C # ). No es simple, pero es posible cambiar el orden del diseño.

Answer 5

Lo que sea que te haga más productivo. A algunos les gustan los campos privados junto a los que tienen acceso a la propiedad, algunos como los campos juntos por encima de los constructores. Lo más importante que puede ayudar es agrupar elementos "me gusta". Personalmente, me gusta reunir métodos privados, propiedades privadas, etc.

Pruebe algunas cosas y nuevamente, lo que sienta lo hace más productivo y lo ayuda a mantener su código actualizado.

Answer 6

No creo que las regiones sean necesariamente un signo de mal código. Pero para determinar que tendrá que revisar lo que tiene. Como dije here así es como clasifico mi código.

Enumeraciones
Declaraciones
Constructores
Métodos
Manejadores de eventos
Propiedades

Pero lo principal es mantenerlo constante y resuelto.

Answer 7

Puede intentar Regionerate para ayudar con esto. Me gusta mucho y es una elección de Scott Hanselman.

Answer 8

Tiendo a agrupar datos privados y tienden a agrupar métodos / propiedades relacionados en grupos funcionales.

public class Whatever {
   // private data here
   int _someVal = kSomeConstant;

   // constructor(s)
   public Whatever() { }

#region FabulousTrick  // sometimes regionize it
   // fabulous trick code
   private int SupportMethodOne() { }
   private double SupportMethodTwo() { }
   public void PerformFabulousTrick(Dog spot) {
       int herrings = SupportMethodOne();
       double pieces = SupportMethodTwo();
       // etc
   }
#endregion FabulousTrick
   // etc
}

Answer 9

Uso el siguiente diseño:

eventos globales / campos de toda la clase propiedades privadas / internas métodos propiedades públicas / protegidas métodos clases anidadas (aunque trato de evitarlas siempre que sea posible)

También creo firmemente en 1 código "cosa" (clase, interfaz o enumeración) por archivo, con el nombre del archivo igual al nombre "cosa". Sí, hace un proyecto más grande pero hace que sea infinitamente más fácil encontrar cosas.

Answer 10

Tiendo a usar Microsoft StyleCop , que tiene un orden establecido de acuerdo con la regla SA1201 :

Causa Un elemento dentro de un archivo de código C # está fuera de servicio en relación con los otros elementos en el código.

Descripción de la regla Una violación de esta regla ocurre cuando los elementos del código dentro de un archivo no siguen un esquema de ordenamiento estándar.

Para cumplir con esta regla, los elementos en el nivel de raíz del archivo o dentro de un espacio de nombre se deben ubicar en el siguiente orden:

• Directivas Externas Alias
• Usando directivas
• Espacios de nombres
• Delegados
• Enums
• Interfaces
• Estructura
• Clases

Dentro de una clase, estructura o interfaz, los elementos deben colocarse en el siguiente orden:

• Campos
• Constructores
• Finalizadores (Destructores)
• Delegados
• Eventos
• Enums
• Interfaces
• Propiedades
• Indizadores
• Métodos
• Estructura
• Clases

Cumplir con un esquema de pedido estándar basado en el tipo de elemento puede aumentar la legibilidad y el mantenimiento del archivo y fomentar la reutilización del código.

Al implementar una interfaz, a veces es deseable agrupar todos los miembros de la interfaz uno al lado del otro. Esto a veces requerirá violar esta regla, si la interfaz contiene elementos de diferentes tipos. Este problema se puede resolver mediante el uso de clases parciales.

1. Agregue el atributo parcial a la clase, si la clase aún no es parcial.

2. Agregue una segunda clase parcial con el mismo nombre. Es posible colocar esto en el mismo archivo, justo debajo de la clase original o dentro de un segundo archivo.

3. Mueva la herencia de la interfaz y todos los miembros de la implementación de la interfaz a la segunda parte de la clase.