Nomes dos membros do tipo
Nota
Este conteúdo é reimpresso com permissão da Pearson Education, Inc., a partir de Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition. Essa edição foi publicada em 2008 e, desde então, o livro foi totalmente revisto na terceira edição. Algumas das informações nesta página podem estar desatualizadas.
Os tipos são feitos de membros: métodos, propriedades, eventos, construtores e campos. As seções a seguir descrevem diretrizes para nomear membros do tipo.
Nomes dos métodos
Como os métodos são o meio de agir, as diretrizes de design exigem que os nomes dos métodos sejam verbos ou frases verbais. Seguir essa diretriz também serve para distinguir nomes de métodos de nomes de propriedades e tipos, que são frases nominais ou adjetivas.
✔️ DO dê nomes de métodos que são verbos ou frases verbais.
public class String {
public int CompareTo(...);
public string[] Split(...);
public string Trim();
}
Nomes de propriedades
Ao contrário de outros membros, as propriedades devem receber nomes substantivos, frases ou adjetivos. Isso ocorre porque uma propriedade se refere a dados, e o nome da propriedade reflete isso. PascalCasing é sempre usado para nomes de propriedades.
✔️ Propriedades do nome DO usando um substantivo, frase nominal ou adjetivo.
❌ NÃO tem propriedades que correspondam ao nome dos métodos "Get" como no exemplo a seguir:
public string TextWriter { get {...} set {...} }
public string GetTextWriter(int value) { ... }
Esse padrão normalmente indica que a propriedade deve realmente ser um método.
✔️ DO nomeia propriedades da coleção com uma frase plural descrevendo os itens na coleção em vez de usar uma frase singular seguida de "List" ou "Collection".
✔️ DO nomeie propriedades booleanas com uma frase afirmativa (CanSeek em vez de CantSeek). Opcionalmente, você também pode prefixar propriedades booleanas com "Is", "Can" ou "Has", mas apenas onde isso agrega valor.
✔️ CONSIDERE dar a uma propriedade o mesmo nome que seu tipo.
Por exemplo, a propriedade a seguir obtém e define corretamente um valor enum chamado Color, portanto, a propriedade é nomeada Color:
public enum Color {...}
public class Control {
public Color Color { get {...} set {...} }
}
Nomes de Eventos
Os eventos sempre se referem a alguma ação, seja uma que está acontecendo ou uma que ocorreu. Portanto, como nos métodos, os eventos são nomeados com verbos, e o tempo verbal é usado para indicar o momento em que o evento é levantado.
✔️ DO nomeie eventos com um verbo ou uma frase verbal.
Exemplos incluem Clicked, Painting, DroppedDown, e assim por diante.
✔️ DÊ nomes aos eventos com um conceito de antes e depois, usando os tempos presentes e passados.
Por exemplo, um evento de fechamento que é gerado antes de uma janela ser fechada seria chamado Closing, e um que é gerado depois que a janela é fechada seria chamado Closed.
❌ NÃO use prefixos ou postfixes "Antes" ou "Depois" para indicar pré e pós-eventos. Use os tempos presentes e passados como acabamos de descrever.
✔️ Manipuladores de eventos de nome DO (delegados usados como tipos de eventos) com o sufixo "EventHandler", conforme mostrado no exemplo a seguir:
public delegate void ClickedEventHandler(object sender, ClickedEventArgs e);
✔️ DO usa dois parâmetros nomeados sender e e em manipuladores de eventos.
O parâmetro sender representa o objeto que gerou o evento. O parâmetro sender é tipicamente do tipo object, mesmo que seja possível empregar um tipo mais específico.
✔️ Classes de argumento de evento de nome DO com o sufixo "EventArgs".
Nomes dos campos
As diretrizes de nomenclatura de campos aplicam-se a campos públicos estáticos e protegidos. Os campos internos e privados não são cobertos pelas diretrizes, e os campos de instância pública ou protegida não são permitidos pelas diretrizes de design do membro.
✔️ USE PascalCasing em nomes de campos.
✔️ Campos de nome DO usando um substantivo, frase nominal ou adjetivo.
❌ NÃO use um prefixo para nomes de campos.
Por exemplo, não use "g_" ou "s_" para indicar campos estáticos.
© Partes 2005, 2009 Microsoft Corporation. Todos os direitos reservados.
Reimpresso com permissão da Pearson Education, Inc., de Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition por Krzysztof Cwalina e Brad Abrams, publicado em 22 de outubro de 2008 por Addison-Wesley Professional como parte da Microsoft Windows Development Series.