Ordem dos itens nas classes: Campos, Propriedades, Construtores, Métodos

Existe uma diretriz oficial em C # para a ordem dos itens em termos de estrutura de classe?

Vai:

• Campos públicos
• Campos Privados
• Propriedades
• Construtores
• Métodos
  ?

Estou curioso para saber se existe uma regra rígida e rápida sobre a ordem dos itens? Estou meio que em todo lugar. Quero seguir um padrão específico para poder fazer isso em qualquer lugar.

O verdadeiro problema é que minhas propriedades mais complexas acabam parecendo muito com métodos e elas parecem deslocadas no topo antes do construtor.

Alguma dica / sugestão?

De acordo com a documentação das regras da StyleCop, o pedido é o seguinte.

Dentro de uma classe, estrutura ou interface: (SA1201 e SA1203)

• Campos Constantes
• Campos
• Construtores
• Finalizadores (Destrutores)
• Delegados
• Eventos
• Enums
• Interfaces ( implementações de interface )
• Propriedades
• Indexadores
• Métodos
• Estruturas
• Aulas

Em cada um desses grupos, faça o pedido por acesso: (SA1202)

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

Dentro de cada um dos grupos de acesso, ordene por estático e depois não estático: (SA1204)

• estático
• não estático

Dentro de cada um dos grupos de campos estáticos / não estáticos, ordene somente leitura e depois não somente leitura: (SA1214 e SA1215)

• somente leitura
• não readonly

Uma lista não enrolada tem 130 linhas, então não a desenrolarei aqui. A parte dos métodos desenrolada é:

• 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

A documentação observa que, se a ordem prescrita não for adequada - por exemplo, várias interfaces estão sendo implementadas e os métodos e propriedades da interface devem ser agrupados -, use uma classe parcial para agrupar os métodos e propriedades relacionados.

Em vez de agrupar por visibilidade ou por tipo de item (campo, propriedade, método etc.), que tal agrupar por funcionalidade?

Esta é uma pergunta antiga, mas ainda muito relevante, então acrescentarei o seguinte: Qual é a primeira coisa que você procura quando abre um arquivo de classe que pode ou não ter lido antes? Campos? Propriedades? Percebi por experiência que quase invariavelmente vou caçar os construtores, porque a coisa mais básica a entender é como esse objeto é construído.

Portanto, comecei a colocar os construtores em primeiro lugar nos arquivos de classe e o resultado foi psicologicamente muito positivo. A recomendação padrão de colocar os construtores atrás de várias outras coisas parece dissonante.

O próximo recurso de construtor primário no C # 6 fornece evidência de que o local natural para um construtor está no topo de uma classe - na verdade, os construtores primários são especificados mesmo antes da chave aberta.

É engraçado quanta diferença uma reordenação como essa faz. Isso me lembra de como as usinginstruções costumavam ser ordenadas - primeiro com os namespaces do sistema. O comando "Organizar usos" do Visual Studio usou esse pedido. Agora, os usings são apenas ordenados alfabeticamente, sem tratamento especial dado aos namespaces do sistema. O resultado parece mais simples e limpo.

Não conheço um idioma ou padrão do setor, mas costumo colocar as coisas nessa ordem com cada seção agrupada em uma # região:

usando instruções

Namespace

Classe

Membros privados

Propriedades públicas

Construtores

Métodos públicos

Métodos particulares

Eu recomendaria usar os padrões de codificação da IDesign ou os listados no site de Brad Abram . Esses são os dois melhores que eu encontrei.

Brad diria ...

O membro das classes deve estar em ordem alfabética e agrupado em seções (Campos, Construtores, Propriedades, Eventos, Métodos, Implementações de Interface Privada, Tipos Aninhados)

Como mencionado anteriormente, não há nada na linguagem C # que dite o layout, eu pessoalmente uso regiões e faço algo assim para uma classe média.

public class myClass
{
#region Private Members

#endregion
#region Public Properties

#endregion

#region Constructors

#endregion
#region Public Methods

#endregion
}

Faz sentido para mim de qualquer maneira

De StyleCop

campos privados, campos públicos, construtores, propriedades, métodos públicos, métodos privados

Como o StyleCop faz parte do processo de criação da MS, você pode vê-lo como um padrão de fato

Normalmente, tento seguir o próximo padrão:

• membros estáticos (geralmente têm outro contexto, devem ser seguros para threads, etc.)
• membros da instância

Cada parte (estática e instância) consiste nos seguintes tipos de membros:

• operadores (sempre estáticos)
• campos (inicializados antes dos construtores)
• construtores
• destruidor ( é uma tradição seguir os construtores )
• propriedades
• métodos
• eventos

Em seguida, os membros são classificados por visibilidade (de menos para mais visível):

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

A ordem não é um dogma: classes simples são mais fáceis de ler, no entanto, classes mais complexas precisam de agrupamentos específicos ao contexto.

Minha preferência é ordenar por tipo e depois diminuir a visibilidade da seguinte forma

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

Sei que isso viola o Style Cop e, se alguém puder me dar uma boa razão para colocar os detalhes de implementação de um tipo antes de sua interface, estou disposto a mudar. Atualmente, tenho uma forte preferência por colocar os membros em último lugar.

Nota: Não uso campos públicos ou protegidos.

O mais próximo que você provavelmente encontrará é "Diretrizes de design, código gerenciado e o .NET Framework" ( http://blogs.msdn.com/brada/articles/361363.aspx ) por Brad Abrams

Muitos padrões são descritos aqui. A seção relevante é 2.8, eu acho.

as únicas diretrizes de codificação que vi sugeridas para isso são colocar os campos na parte superior da definição da classe.

Eu costumo colocar os construtores a seguir.

meu comentário geral seria que você deveria manter uma classe por arquivo e, se a classe for grande o suficiente para que a organização das propriedades versus métodos seja uma grande preocupação, qual é o tamanho da classe e você deve refatorá-la de qualquer maneira? representa várias preocupações?

Eu prefiro colocar os campos privados no topo junto com o (s) construtor (es), depois colocar os bits da interface pública depois disso, depois os bits da interface privada.

Além disso, se a definição de sua classe for longa o suficiente para que a ordem dos itens seja importante, provavelmente é um cheiro de código indicando que sua classe é muito volumosa e complexa e você deve refatorar.

Eu mantenho o mais simples possível (pelo menos para mim)

Enumerações
Declarações
Construtores
Substitui
Métodos
Propriedades
Manipulador de Eventos

Certamente não há nada na linguagem que a imponha de maneira alguma. Costumo agrupar as coisas por visibilidade (pública, depois protegida e depois privada) e usar #regions para agrupar as coisas relacionadas funcionalmente, independentemente de ser uma propriedade, método ou qualquer outra coisa. Os métodos de construção (sejam os reais ou as funções estáticas da fábrica) geralmente estão no topo, pois são a primeira coisa que os clientes precisam saber.

Sei que isso é antigo, mas meu pedido é o seguinte:

em ordem pública, protegida, privada, interna, abstrata

• Constantes
• Variáveis ​​estáticas
• Campos
• Eventos
• Construtor (es)
• Métodos
• Propriedades
• Delegados

Também gosto de escrever propriedades como esta (em vez da abordagem abreviada)

// 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; }
}