Microsoft estendeu o conjunto de regras de análise de código de regras de diretrizes de Design
O conjunto de regras de regras de diretrizes de Design do Microsoft Extended expande as regras de diretriz de design básica para maximizar as questões de usabilidade e a sustentabilidade são relatadas. Ênfase adicional é colocado em diretrizes de nomenclatura. Você deve considerar incluindo esta regra definir se o seu projeto inclui o código da biblioteca ou se você deseja impor os mais altos padrões para escrever código que é fácil de manter.
As regras de diretriz de Design estendidos incluem todas as regras de diretriz de Design básico do Microsoft. As regras básicas de diretriz de Design incluem todas as regras do Microsoft mínimo recomendado. Para obter mais informações, consulte Conjunto de regras de análise de código de regras de diretrizes de Design Microsoft Basic e Microsoft mínimo recomendado de conjunto de regras de análise de código de regras
A tabela a seguir descreve todas as regras do conjunto de regras de regras de diretrizes de Design do Microsoft estendido.
Regra |
Descrição |
|---|---|
Certifique-se de que há uma organização lógica para cada um dos seus espaços para nomes e que há um motivo válido para a colocação de tipos em um namespace de modo disperso preenchido. |
|
Tipos de passagem por referência (usando out ou ref) requer experiência com ponteiros, entender a diferença entre os tipos de valor e tipos de referência e tratamento métodos com vários valores de retorno. Além disso, a diferença entre o check-out e parâmetros ref não é amplamente sabido. |
|
Interfaces definir membros que fornecem um contrato de uso ou comportamento. A funcionalidade descrita pela interface pode ser adotada por qualquer tipo, independentemente de onde o tipo aparece na hierarquia de herança. Um tipo implementa uma interface fornecendo implementações de membros da interface. Uma interface vazia não define quaisquer membros; Portanto, ele não define um contrato que pode ser implementado. |
|
Tipos de passagem por referência (usando out ou ref) requer experiência com ponteiros, entender a diferença entre os tipos de valor e tipos de referência e tratamento métodos com vários valores de retorno. Os arquitetos de biblioteca que projetar para o público em geral não devem esperar que os usuários trabalhando mestre com check-out ou parâmetros ref. |
|
Todos os argumentos de referência passados para métodos visíveis externamente devem ser verificados em relação a null. |
|
Um tipo é a mais de quatro níveis de profundidade na sua hierarquia de herança. Hierarquias de tipo aninhado profundamente podem ser difícil siga, entender e manter. |
|
O nome de um campo de instância começa com "s_" ou o nome de um campo de estático (Shared no Visual Basic) começa com "m"(_). |
|
Um tipo ou método tem um valor de índice de baixa manutenção. Um índice de baixa manutenção indica que um tipo ou método é difícil manter provavelmente seria um bom candidato para replanejamento. |
|
Esta regra mede o acoplamento contando o número de referências de tipo único que contém a um tipo ou método de classe. |
|
Esta regra pressupõe que um membro de enumeração com um nome que contenha "reservado" não é usado no momento, mas é um espaço reservado para ser renomeado ou removido em uma versão futura. Renomear ou remover um membro é uma alteração significativa. |
|
CA1701: Palavras compostas de seqüência de recurso devem ser minúsculas corretamente |
Cada palavra na seqüência de recurso é dividida em tokens baseados nas maiúsculas e minúsculas. Cada combinação de dois token contígua é verificada pela biblioteca do verificador ortográfico do Microsoft. Se reconhecido, a palavra produz uma violação da regra. |
CA1702: Palavras compostas devem ser minúsculas corretamente |
O nome de um identificador contém várias palavras e pelo menos uma das palavras que parece ser uma palavra composta que não é causada corretamente. |
CA1703: Seqüências de recursos devem ser escritas corretamente |
Uma seqüência de recurso contém uma ou mais palavras que não são reconhecidas pela biblioteca do verificador ortográfico do Microsoft. |
O nome de um identificador visível externamente contém uma ou mais palavras que não são reconhecidas pela biblioteca do verificador ortográfico do Microsoft. |
|
Por convenção, os nomes de identificador não contêm o caractere de sublinhado (_). Esta regra verifica os namespaces, tipos, membros e parâmetros. |
|
Por convenção, os nomes de parâmetro usam camel casing, enquanto o espaço para nome, tipo, e os nomes de membro Pascal casing. |
|
Por convenção, os nomes de tipos que ampliam a determinados tipos de base ou que implementar determinadas interfaces ou tipos derivados desses tipos tem um sufixo que está associado com o tipo base ou interface. |
|
Por convenção, apenas os nomes dos tipos que ampliam a determinados tipos de base ou que implementar determinadas interfaces ou tipos derivados desses tipos, devem terminar com os sufixos específicos de reservado. Outros nomes de tipo não devem usar esses sufixos reservados. |
|
Nomes de membros de enumeração não são prefixados com o nome do tipo, porque o tipo de informações são esperadas a serem fornecidos pelas ferramentas de desenvolvimento. |
|
O nome de um evento começa com "Antes" ou "Depois". Para nomear os eventos relacionados que são gerados em uma seqüência específica, use o presente ou o indicativo do passado para indicar a posição relativa na seqüência de ações. |
|
Uma enumeração pública tem o atributo FlagsAttribute e seu nome não termina em "s". Tipos marcados com FlagsAttribute têm nomes que estão no plural, porque o atributo indica que mais de um valor pode ser especificado. |
|
O nome de uma interface visível externamente não inicia com um "I" maiúsculo. O nome de um parâmetro de tipo genérico em um tipo visível externamente ou método não inicia com "T" maiúsculo. |
|
CA1717: Somente os enums FlagsAttribute devem ter nomes plural |
Convenções de nomenclatura determinam que um nome no plural para uma enumeração indica o que mais de um valor da enumeração pode ser especificado ao mesmo tempo. |
CA1719: Nomes de parâmetro não devem corresponder a nomes de membro |
O nome do parâmetro deve comunicar o significado de um parâmetro e um nome de membro deve comunicar o significado de um membro. Seria um design raro onde elas eram os mesmos. Nomeando um parâmetro da mesma como seu nome de membro é não intuitivos e dificulta a biblioteca de usar. |
O nome do parâmetro em um membro visível externamente contém um nome de tipo de dados ou o nome de um membro visível externamente contém um nome de tipo de dados específicos do idioma. |
|
CA1721: Os nomes de propriedade não devem corresponder a métodos get |
O nome de um membro público ou protegido começa com "Get" Caso contrário, corresponde ao nome de uma propriedade pública ou protegida. " Get" métodos e propriedades devem ter nomes de distinguir claramente sua função. |
Por convenção, somente determinados elementos de programação têm nomes que começam com um prefixo específico. |
|
Nomes de tipo não devem corresponder os nomes dos namespaces definido na.Biblioteca de classes do NET Framework. Violam essa regra pode reduzir a usabilidade da biblioteca. |
|
CA1725: Nomes de parâmetro devem corresponder à declaração de base |
Nomeação consistentes de parâmetros em uma hierarquia de substituição aumenta a usabilidade de substituições de método. Um nome de parâmetro em um método derivado que difere do nome na declaração de base pode causar confusão sobre se o método é uma substituição do método base ou uma nova sobrecarga do método. |
O nome de um identificador visível externamente inclui um termo para o qual um termo alternativo, preferencial existe. Como alternativa, o nome inclui o termo "Bandeira" ou "Sinalizadores". |
|
Uma seqüência de caracteres literal no corpo do método contém uma ou mais palavras que não são reconhecidas pela biblioteca do verificador ortográfico do Microsoft. |