Convenções de nomenclatura gerais

Esta seção descreve as convenções gerais de nomenminação relacionadas à escolha de palavras, diretrizes sobre como usar abreviações e acrônimos e recomendações sobre como evitar o uso de nomes específicos do idioma.

Escolha do Word

✔️ ESCOLHA nomes de identificadores facilmente acessíveis.

Por exemplo, uma propriedade chamada HorizontalAlignment é mais acessível em inglês do que AlignmentHorizontal .

✔️ DO favorecem a capacidade de leitura em relação à brevidade.

O nome da CanScrollHorizontally propriedade é melhor do que ScrollableX (uma referência obscurecida ao eixo X).

❌ NÃO use sublinhados, hifens ou outros caracteres nãoumeéricos.

❌ NÃO use a notação hóscia.

❌ EVITE usar identificadores que conflitam com palavras-chave de linguagens de programação amplamente usadas.

De acordo com a Regra 4 do CLS (Common Language Specification), todos os idiomas em conformidade devem fornecer um mecanismo que permita acesso a itens nomeados que usam uma palavra-chave desse idioma como um identificador. O C#, por exemplo, usa o sinal @ como um mecanismo de escape nesse caso. No entanto, ainda é uma boa ideia evitar palavras-chave comuns porque é muito mais difícil usar um método com a sequência de escape do que uma sem ele.

Usando abreviações e acrônimos

❌ NÃO use abreviações ou contrações como parte de nomes de identificadores.

Por exemplo, use GetWindow em vez de GetWin .

❌ NÃO use nenhum acrônimo que não seja amplamente aceito e, mesmo se eles são, somente quando necessário.

Evitando nomes Language-Specific dados

✔️ USAR nomes semanticamente interessantes em vez de palavras-chave específicas de idioma para nomes de tipo.

Por exemplo, GetLength é um nome melhor do que GetInt .

✔️ USAR um nome de tipo CLR genérico, em vez de um nome específico a um idioma, nos casos raros em que um identificador não tem nenhum significado semântico além de seu tipo.

Por exemplo, um método que converte para deve ser chamado , não (porque é um nome CLR para o alias específico Int64 ToInt64 de ToLong Int64 long C#). A tabela a seguir apresenta vários tipos de dados base usando os nomes de tipo CLR (bem como os nomes de tipo correspondentes para C#, Visual Basic e C++).

C# Visual Basic C++ CLR
sbyte Sbyte char Sbyte
byte Byte unsigned char Byte
short Curto short Int16
ushort UInt16 unsigned short UInt16
int Inteiro int Int32
Uint UInt32 unsigned int UInt32
longo Long __int64 Int64
Ulong UInt64 unsigned __int64 UInt64
float Single float Single
double Double double Double
bool Booliano bool Booliano
char Char Wchar_t Char
cadeia de caracteres Cadeia de caracteres Cadeia de caracteres Cadeia de caracteres
object Objeto Objeto Objeto

✔️ USE um nome comum, como ou , em vez de repetir o nome do tipo, nos casos raros em que um identificador não tem nenhum significado semântico e o tipo do parâmetro não value item é importante.

Nomeando novas versões de APIs existentes

✔️ USE um nome semelhante à API antiga ao criar novas versões de uma API existente.

Isso ajuda a realçar a relação entre as APIs.

✔️ preferir adicionar um sufixo em vez de um prefixo para indicar uma nova versão de uma API existente.

Isso ajudará na descoberta ao navegar pela documentação ou usando o IntelliSense. A versão antiga da API será organizada perto das novas APIs, porque a maioria dos navegadores e do IntelliSense mostra identificadores em ordem alfabética.

✔️ CONSIDERE usar um identificador novo, mas significativo, em vez de adicionar um sufixo ou um prefixo.

✔️ USE um sufixo numérico para indicar uma nova versão de uma API existente, especialmente se o nome existente da API for o único nome que faça sentido (ou seja, se for um padrão do setor) e se adicionar qualquer sufixo significativo (ou alterar o nome) não for uma opção apropriada.

❌ NÃO use o sufixo "Ex" (ou semelhante) para um identificador para diferenciá-lo de uma versão anterior da mesma API.

✔️ USE o sufixo "64" ao introduzir versões de APIs que operam em um inteiro de 64 bits (um inteiro longo) em vez de um inteiro de 32 bits. Você só precisa tomar essa abordagem quando a API de 32 bits existente existir; não faça isso para APIs novas com apenas uma versão de 64 bits.

Partes © 2005, 2009 Microsoft Corporation. Todos os direitos reservados.

Reimpresso com permissão da Pearson Education, Inc. das Diretrizes de Design do Framework: convenções, linguagens e padrões para bibliotecas do .NET reutilizável, 2ª edição por Krzysztof Cwalina e Brad Abrams, publicado em 22 de outubro de 2008 por Addison-Wesley Professional como parte da série de desenvolvimento do Microsoft Windows.

Confira também