Guia Prático de Nomenclatura para Visual Basic .NET (cap 3 e 4)
Com foco no Visual Studio
- Princípios Gerais e Diretrizes de Nomenclatura
- Configurar o Visual Studio
- Dicas de Ouro
- Recomendações Além do
.editorconfig - Mais Conteúdos Relacionados
3. Dicas de Ouro
Para fechar com chave de ouro, aqui estão quatro dicas cruciais que costumam passar despercebidas por quem está configurando padrões no VB.NET:
3.1 Cuidado com o "Case-Insensitivity" (Insensibilidade a Maiúsculas)
Diferente do C#, o VB.NET não diferencia minhavariavel de MinhaVariavel.
Se você definir uma Propriedade chamada Cliente e tentar criar um Campo Privado chamado cliente (sem o underscore), o compilador vai gerar um erro de "nome duplicado".
- A dica: O uso do underscore (
_cliente) não é apenas estética no VB.NET, é uma necessidade técnica para evitar colisões de nomes.
3.2 O Recurso "Pretty Listing" (Reformatação Automática)
O Visual Studio tem uma função nativa chamada Pretty Listing que tenta corrigir o "case" (maiúsculas/minúsculas) enquanto você digita.
- Se você digitar
dim x as stringe apertar Enter, ele muda paraDim x As String. - A dica: Se o Visual Studio parar de fazer isso ou você quiser ajustar, vá em: Ferramentas > Opções > Editor de Texto > Basic > Avançado e verifique a opção Pretty listing (reformatting) of code.
3.3 Namespaces e a Estrutura de Pastas
No .NET, é uma convenção (embora não obrigatória) que o seu Namespace reflita a estrutura de pastas do seu projeto.
- Se você tem uma pasta chamada
Servicos, o código lá dentro deve estar sob o namespaceSeuProjeto.Servicos. - A dica: Mantenha os nomes das pastas em PascalCase para que, ao gerar o namespace automaticamente, ele já siga o padrão correto.
3.4 XML Documentation (Comentários de Código)
Ao definir nomes perfeitos, aproveite para documentá-los. No VB.NET, ao digitar três aspas simples (''') acima de uma função ou classe, o Visual Studio gera um template XML.
- A dica: O Visual Studio usa o nome que você definiu no padrão para preencher os campos de ajuda do IntelliSense. Isso torna sua biblioteca muito mais profissional para outros desenvolvedores.
4. Recomendações Além do .editorconfig
O arquivo .editorconfig é uma ferramenta poderosa para impor automaticamente convenções de nomenclatura e estilo, especialmente quando integrado aos analisadores do Roslyn.
No entanto, ele não é — nem pretende ser — um mecanismo completo de governança semântica do código.
Por isso, este guia adota uma separação clara entre:
- Regras que podem ser impostas automaticamente
- Regras que não podem ser impostas automaticamente
- Regras que poderiam ser impostas, mas optamos por não incluir
- Boas práticas que dependem de julgamento humano
As recomendações abaixo existem exatamente para cobrir essas lacunas.
4.1 Limitações Técnicas Reais do .editorconfig
O .editorconfig consegue impor regras estruturais e sintáticas, baseadas em:
- Tipo do símbolo (
class,method,field,delegate,local_function, etc.) - Acessibilidade (
public,private, etc.) - Modificadores (
const,static,async) - Estilos de capitalização e prefixos/sufixos simples
Entretanto, as regras de nomenclatura nativas do .editorconfig (dotnet_naming_rule, dotnet_naming_symbols, etc.) não possuem compreensão semântica profunda. Isso significa que elas não conseguem expressar regras baseadas em herança, comportamento real ou intenção de domínio.
Por exemplo, não é possível criar uma naming rule que:
- Valide herança diretamente (ex.: garantir via dotnet_naming_rule que toda classe que herda de
System.Exceptiontermine comException) - Valide comportamento (ex.: exigir sufixo
Asyncapenas para métodos que realmente usamawait) - Infira intenção de domínio (ex.: distinguir entidades, serviços, DTOs ou Value Objects)
- Avalie contexto arquitetural (ex.: regras diferentes para código de produção e código de teste)
Observação importante: Embora as naming rules do
.editorconfigtenham essas limitações, o ecossistema .NET inclui Roslyn Analyzers (como CA1710 e CA1711) que conseguem validar sufixos com base em herança. Esses analyzers podem ser habilitados e configurados via.editorconfig, mas não fazem parte das naming rules em si.
Essas limitações não são falhas — são limitações conhecidas e documentadas das regras de nomenclatura nativas do .editorconfig, motivo pelo qual convenções mais semânticas exigem analyzers ou revisão humana.
4.2 Convenções Semânticas que Devem Ser Seguidas Manualmente
Algumas convenções amplamente aceitas na plataforma .NET não podem ser impostas com segurança via .editorconfig, mas continuam sendo obrigatórias neste guia:
- Interfaces devem iniciar com o prefixo
I - Exceções devem terminar com o sufixo
Exception - Atributos devem terminar com o sufixo
Attribute - Métodos assíncronos devem terminar com o sufixo
Async - Delegates devem usar nomes que expressem ação ou evento (
Handler,Callback, etc.)
Essas regras dependem de significado e intenção, não apenas de forma — portanto, devem ser validadas em revisão de código.
4.3 Regras Deliberadamente não Incluídas no .editorconfig
Existem casos em que o .editorconfig até permitiria alguma forma de validação, mas o guia opta conscientemente por não automatizar, por razões como:
- Excesso de ruído de warnings
- Complexidade desnecessária de configuração
- Convenções que variam conforme o domínio ou o time
Exemplos:
- Prefixos semânticos para booleanos (
Is,Has,Can) - Convenções específicas para membros de
Enum - Nomenclatura de tipos genéricos além do padrão
T,TValue, etc. - Regras diferentes para código de infraestrutura, domínio ou testes
Nesses casos, a clareza, legibilidade e a intenção comunicada têm prioridade sobre enforcement automático.
4.4 O Papel Complementar de Outras Ferramentas
Para equipes que desejam um nível ainda maior de rigor, o .editorconfig pode (e deve) ser complementado por:
- Analyzers customizados (Roslyn Analyzers)
- Regras do StyleCop
- Revisões de código criteriosas
- Documentação viva do guia de estilo
- Ferramentas de formatação (
dotnet format)
O .editorconfig define a linha de base automática.
O restante da qualidade vem de disciplina técnica e cultura de código.
4.5 Princípio Orientador deste Guia
Este guia segue o princípio de que:
Nem toda regra deve ser automatizada — mas toda regra importante deve ser documentada.
O .editorconfig é usado onde ele é forte.
As recomendações adicionais existem onde o discernimento humano é insubstituível.
Essa combinação é o que garante consistência, legibilidade e longevidade do código sem transformar o processo em algo rígido ou burocrático.
5. Mais Conteúdos Relacionados
Desenvolver também exige saber usar o Git;
estou compartilhando aqui mesmo no TabNews um Glossário de Termos Git e GitHub.
Se você quiser uma grande ajuda da Inteligência Artificial para escrever comentários naquele código que você não está entendendo; então visite esse post que eu fiz especialmente para te ajudar: [ChatGPT] Escrevendo Mensagens de Commit e Comentando Código