Código Limpo – Parte 02: Dando nome aos Bois

“Diga o que você quer expressar. Expresse o que você quer dizer.” –  Robert C Martin

O que mais fazemos em programação é dar nome para tudo, seja para projeto, classe, pacote, classe, método, variáveis etc. Se isto é o que mais fazemos, é melhor que seja feito da melhor forma possível, melhorando assim, a qualidade do nosso código.

Capítulo 02

Se escrevemos nomes o tempo todo, o melhor que temos a fazer é aprender a fazer direito a “Parada”, uma das primeiras dicas que o autor do livro nos dá é: Sempre que achar conveniente mudar o nome de algo, faça-o, mudar nomes hoje é uma das grandes facilidades das IDEs modernas, como Eclipse. Uma dica que posso dar, é a tecla de atalho para renomear “coisas” no eclipse, para fazer isto basta colocar o cursor do mouse sobre o que se quer renomear e pressionar as teclas CTRL+ALT+R (Windows) ou COMMAND + OPTION + R (MAC), dessa maneira é possível renomear no Eclipse.

Devemos também, sempre que escolher um nome, avaliar se o mesmo revela seu propósito, se ele realmente faz o que diz em seu nome (Desculpa repetir a palavra nome varias vezes), uma citação que o Tio Bob faz é a seguinte, “Se um nome requer um comentário, então ele não revela seu propósito!”

Um dos vícios que trazemos do meio acadêmico (Faculdade/Escola) quando se está aprendendo programação, é fazer o uso de variáveis que não dizem exatamente nada para o leitor, nesta hora vale lembrar o que foi dito no outro post, ler um código bem escrito, é como ler uma boa prosa, imagine se Fernando Pessoa escrevesse seus poemas assim: “ Tudo v a p qd a al n é pq.” Hein?! Não dá para entender nada né! Dessa mesma forma uma variável

int d; // A unica informação que temos é do tipo da variavel! E o resto? 

E agora? O que esse d significa? Absolutamente nada. Mas se seu nome fosse:

     int diasQueFaltamParaAnoNovo;
     // Isto Significaria bem mais para o leitor.

Outra coisa que devemos evitar enquanto codificamos é evitar passar informações erradas ou com mais de um significado, uma variável HP por exemplo, poderia significar o nome de uma empresa famosa ou também poderia significar, horas por minuto, sei que tudo depende de um contexto, mas devemos sempre que possível evitar esse tipo erro. Assim como devemos evitar usar a letra “O” maiúscula ou “l” minúscula, porque se parecem muito com 0 e 1 respectivamente, isto claro, se fôssemos usar um nome de uma letra apenas, (o que ja dissemos para ser evitado).

Agora me digam, qual a diferença de:

 XYZControllerForEfficientHandlingOfString

para:

 XYZControllerForEfficientStorageOfString

Meio complicado de dizer né? Este exemplo foi tirado do livro, e podemos tirar uma lição disto: Evite nomes muito parecidos, eles atrapalham na hora da leitura e entendimento do mesmo. Da mesma forma, não devemos mudar os nomes de uma forma arbitrária, ou seja, devemos fazer distinções significativas, não podemos colocar um numero na frente de um nome, só porque ele já existe no código, ou então escrever o nome errado apenas para que seja diferente e o código rode!

Use nomes pronunciáveis, este é um dos subcapítulos do livro, eu entendo que os programadores passam a maior parte do tempo isolados do mundo, escrevendo código sem conversar com os outros desenvolvedores, mas quando temos que perguntar para outro programador se ele alterou determinada variável, é melhor que este nome seja pronunciável, para esclarecer isto Martin, diz que em uma determinada empresa, existe a variável

 genymdhms 

tente pronunciar isto, complicado. Poderíamos evitar isto, criando a variável:

 generationTimestamp; 

ou qualquer outra que facilitasse a pronuncia.

Uma tópico importante a ser abordado é o caso da notação Húngara (escrever o tipo da variável junto ao nome), nos dias atuais, com linguagens modernas como Java, o seu uso deixou de ser importante, uma vez que os objetos já são do próprio tipo que são declarados. As IDEs atuais, ainda facilitam esse trabalho, identificando quando o programador tenta fazer uso impróprio de um objeto.

Uma outra dica importante, é evitar brincadeiras, com nomes que possam conter duplo sentido, não devemos fazer brincadeiras ou dar uma de espertinho, colocando nomes que apenas você entende, isto é muito anti-ético!

Agora sim, vamos as convenções JAVA para nomenclatura:

Convenção de Código Java da Sun [3]

Pelas estimativas da Sun [3], ao longo da vida útil de um código padrão, 20% do esforço será empregado em desenvolvimento e na criação de testes, e 80% será desperdiçado na manutenção e refatoração do código. Com um padrão, esse tempo seria diminuido, por este motivo a Sun criou um conjunto de boas práticas a ser seguidas.

  • Classes

Nomes de classes são normalmente substantivo, a primeira letra sempre deve ser maiúscula, para palavras compostas elas devem ser seguir o formato conhecido como camelCase (primeira letra das palavras internas maiúsculas);

 Dog; 
 PrintWriter;
  • Interfaces

Segue a regra das classes, mas os nomes de Interfaces devem sempre que possível ser um adjetivo, alguns desenvolvedores usam o prefixo I antes do nome ou o sufixo Impl depois do nome, para as implementações:

 IDao; 
 DaoImpl; 

Mas a boa pratica diz que devemos sempre que possível colocar o nome da interface que faça uso de nomes que mostrem seu propósito, por exemplo temos a Interface List, o a implementação ArrayList, que é um List usando Array, veja que o nome mostra exatamente o que se trata a implementação;

  • Métodos

Dever fazer pares de verbo-substantivo, além de conter a primeira letra minuscula, e as demais fazendo o uso do camelCase:

 getNome;
  • Variáveis

As variáveis deve seguir os passos citados nos métodos com relação ao camelCase, as variáveis devem conter nomes pequenos e significativos;

  • Constantes

Essas constantes são marcadas como static e final, usando todos os caracteres maiúsculos e separados por underscore quando houver palavras compostas;

 VALOR_CONSTANTE; 
  • Testes

As classes de testes devem também manter um padrão para que haja uma melhor interpretação e leitura do código, as classes de testes devem conter a palavra Test como sufixo, logo após o nome, este nome dever ser o mesmo nome da classe “original”, o nome do pacote de teste deve ser o mesmo que o do pacote original, mas com o source diferente, normalmente se usa o source test.

O que eu tinha para falar era isso pessoal, espero que tenham gostado, estou trabalhado para trazer o melhor para a comunidade de desenvolvedores, vou continuar com os resumos, quero também fazer posts sobre Testes, que é um assunto que estou estudando e também alguma coisa de configuração do eclipse, espero que tenham gostado, qualquer erro me avisem, até a próxima!

[1] Nomenclatura – http://www.javabuilding.com/principles/nomenclatura.html

[2] Código Limpo – Habilidades, Práticas do Agile Software (Robert C. Martin)

[3] SCJP – Certificado Sun® para Programador Java™ 6

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s