Estou no meio de uma consultoria, o cliente me pede para ver o código. Eu vou ver o código, claro. Eu olho a classe, olho os métodos, não entendo nada.
"ClienteDB". Isso é nome de classe? O que será que quer dizer? Deixa eu ver o nome das funções. "ObterDados". Nossa, que dados serão esses? Devem ser do cliente, e deve ter alguma coisa a ver com um banco de dados (tem o tal "DB" no final). Mas retorna booleano! Será que esses dados são da conexão com o banco de dados? Não, não, tem um método aqui chamado "Configurar". Configurar… o quê? Será que é a conexão também? Ou será que é configurar o cliente?
Vou então examinar as variáveis. Dentro de um método encontro variáveis com nomes muito interessantes:
- "obj";
- "oCliente";
- "i";
- "cmp".
Agora ficou fácil!
O mesmo acontece quando estou dando aula. Vem o aluno e me mostra a classe. "Quarto". Métodos: "dormir" e "acordar". O quarto pode dormir? Tudo bem, são alunos, eles podem. Aí é legal, o aluno entende que está aprendendo, aproveita as sugestões e vai em frente, no próximo ele acerta. Mas programadores experientes?
Nomear classes (e funções, propriedades, eventos, ou seja, estruturas em geral) é importante. Se você não consegue dar um nome para sua classe, talvez ela esteja violando o princípio da responsabilidade única. Ou talvez ela não tenha um conceito sólido. De qualquer forma, não dê qualquer nome, é pior. Dê um nome expressivo.
Não se esqueça de que o usuário final da aplicação não é o único. O próximo desenvolvedor que vier depois de você dar manutenção na aplicação também é usuário, só que de outro ponto de vista.
Além disso, não use notação húngara em objetos de negócio. Se você gosta muito de notação húngara, use apenas em objetos de GUI, como txtNome, para textboxes. Não crie "oCliente", ou "objCliente", ou "cliNovo". Não crie "intAnos". Se são anos, só podem ser inteiros, chame de "anos"! Se é um cliente novo, chame de "clienteNovo". Fica mais fácil de ler.
Entrando em uma questão mais de estilo pessoal:
Não use underline/underscore para definir nomes. Nada pior que "nome_completo". Use lower CamelCase para variáveis e campos, como "nomeCompleto", e upper CamelCase para classes, métodos, eventos e propriedades "NomeCompleto", "Andar()", "Click". E use this (C#)/Me(VB) quando acessar campos ou propriedades de uma classe.
Enfim, torne seu código legível (questões de estilo – CamelCase, húngara, underline, etc), e expressivo (usando nomes que explicam a estrutura que nomeiam). O mundo inteiro agradece.
Giovanni Bassi
Arquiteto e desenvolvedor, agilista, escalador, provocador. É fundador e CSA da Lambda3. Programa porque gosta. Acredita que pessoas autogerenciadas funcionam melhor e por acreditar que heterarquia é mais eficiente que hierarquia. Foi reconhecido Microsoft MVP há mais de dez anos, dos mais de vinte que atua no mercado. Já palestrou sobre .NET, Rust, microsserviços, JavaScript, TypeScript, Ruby, Node.js, Frontend e Backend, Agile, etc, no Brasil, e no exterior. Liderou grupos de usuários em assuntos como arquitetura de software, Docker, e .NET.