Clean Code – NOMES SIGNIFICATIVOS
No geral, o que mais fazemos no código é dar nome aos bois: variáveis, funções, parâmetros, classes e pacotes, arquivos-fonte, diretórios… nomes e mais nomes. A seguir vão as regras para nomes mais relevantes pra mim neste livro:
- Use nomes que revelam o seu propósito: Escolher nomes leva tempo, mas economiza mais. Nomeie de forma que diga porquê ele existe, o que faz e como é utilizado.
“Se um nome requer um comentário, então ele não revela o seu propósito.”
- Evite informações erradas: Devemos evitar passar informações falsas que confundam o sentido do código. Mesmo que esteja nomeando uma lista, não coloque o tipo da variável no nome. Nomes podem gerar confusão, assim como a letra “l” minúscula ou “O” maiúscula que podem se parecer com um e zero, respectivamente.
- Faça distinções significativas: Nós programadores criamos problemas para sí próprios quando criamos um código voltado unicamente para um compilador ou interpretador. Não basta adicionar números ou palavras mais comuns, mesmo que o compilador esteja satisfeito. Se os nomes precisam ser diferentes, então também devem ter significados distintos. Faça a distinção dos nomes de forma que o leitor compreenda as diferenças. Abaixo seguem alguns nomes que podem fazer confusão sobre qual função deve ser chamada.
getActiveAccount();getActiveAccounts();getActiveAccountInfo();
- Use nomes pronunciáveis: Se não souber pronunciar o nome, não terá como discutir sobre esse nome sem parecer um idiota. Um exemplo de nome ruim:
private Date modymdhms;
“Isso importa, porque a programação é uma atividade social.”
- Use nomes passíveis de busca: Nomes de uma letra só letra ou números possuem um problema em particular por não serem fáceis de localizá-los ao longo do texto.
Utilize nome de uma letra só, quando se tratar de variáveis locais dentro de métodos pequenos.
Um exemplo de um nome fácil de localizar:const int NUMBER_OF_TAKS;
“O tamanho de um nome deve ser proporcional ao tamanho do escopo.”
- A Notação Húgara: Nos tempos primórdios, era necessário colocar o tipo da variável no nome, a fim de identificar o tipo, uma vez que os compiladores naquela época não identificavam os tipos e não os tornavam obrigatório como nos compiladores de hoje em dia.
A NH e outras convenções de nomes acabam sendo obstáculos e podem induzir o leitor ao erro. Por exemplo:PhoneNumber phoneString; //O nome não muda a alteração do tipo
- Interfaces e Implementações: Evite utilizar “I” para nomear interfaces por exemplo. E ao criar a classe que a implementa, procure utilizar como no exemplo:
ShapeFactory -> ShapeFactoryImpl
- Evite o mapeamento mental: Os leitores não devem ter que traduzir os nomes que você escreveu, por nomes que eles conheçam. Este é um problema com variáveis de uma letra só. Certamente um contador pode ser chamado de “i” “j” ou “k”, mas nunca “l”, se o escopo for pequeno e não houver outros nomes que possam entrar em conflito com ele.
- Nome de classes: Classes e objetos devem ter o nomes com substantivos(s). Seguem alguns exemplos:
CustomerWikiPageAccountAdressParser
- Nome de métodos: Os métodos devem ter verbos. Seguem alguns exemplos:
PostPaymentDeletePageSave
Devem ser nomeados nome de métodos de acesso, alteração e autenticação segundo seus valores e adicionar prefixos get, set ou is de acordo com o padrão javabean.
Quando os construtores estiverem em sobrecarga, utilize métodos de fábrica estáticos com nomes que descrevam os parâmetros. Por exemplo:
-
Complex fulcrumPoint = Complex.FromRealNumber(23.0);
é melhor que Complex fulcrumPoint = new Complex(23.0);
Para reforçar seu uso, torne os construtores correspondentes como privados.
- Não faça trocadilhos: Se você tem um contexto onde todas as classes contém um método add que faz a adição de uma concatenação de dois valores existentes, e agora precisa criar uma nova classe que coloque apenas um item numa coleção. Você deve se perguntar se este método deve se chamar add. Neste caso, a semântica é diferente. talvez um insert ou append serviriam.
- Não adicione contextos desnecessários: Em um exemplo onde temos um app chamado “Gas Station Deluxe” seria uma péssima ideia adicionar o prefixo em toda a parte como GDSAccountAdress. Dez dos 17 caracteres são redundantes ou irrelevantes.
Nomes curtos são melhores contanto que sejam claros.
O mais difícil de escolher bons nomes é a necessidade de possuir boas habilidades de descrição em um contexto histórico cultural compartilhado. É uma questão de aprender, e não uma técnica gerencial ou empresarial.
Siga alguma das regras acima e verifique se seu código melhorou ou não a legibilidade. Se estiver fazendo manutenção do código de outra pessoa, use ferramentas de refatoração para ajudar. Em pouco tempo valerá a pena para um longo prazo.