Nomes significativos
Nesse segundo capítulo o autor trata da importância dos nomes em um código, desde o nome do projeto até os nomes das variáveis, exemplificando nomes adequados e destacando consequências de nomes ruins, resgatando o conceito de autor de código levantado no capítulo anterior, o código precisa ser legível.
Use Nomes que revelem o seu proposito
Escolher bons nomes leva tempo e o primeiro nome pode não ser o mais adequado, então é importante escolher um nome adequado e que não deixe dúvidas sobre o funcionamento do código, isso vai facilitar que os outros e o próprio autor entendam o código.
O nome de uma função ou classe deve responder as seguintes questões:
- Porque existe?
- Oque faz?
- Como é usado?
Evite informações erradas
Uma informação errada é ainda pior do que informação nenhuma, porque pode confundir o leitor do código. Um grupo de contas nunca deve ser nomeado como accountList se não for de fato uma lista por exemplo.
Devem ser evitados nomes muito parecidos, quando isso se torna necessário, convém utilizar do recurso de auto completar das IDE's e criar uma lógica que distingue facilmente os nomes.
Também devem ser evitados caracteres que são semelhantes muito próximos como o I, l e 1, ou o, O e 0.
Faça distinções significativas
Muitas vezes é necessário utilizar nomes similares, ao invés de simplesmente criar userAccount1, userAccount2 e userAccount3, é preferível utilizar userAccount, userAccounts e userAccountInfo, mas mesmo assim, separadamente os nomes não significam muita coisa, é o autor quem deve cuidar para que os nomes escolhidos sigam uma lógica no código e façam sentido.
Use nomes pronunciáveis
O autor deve tirar proveito da língua falada ao atribuir nomes e isso tornará o código mais legível, é muito simples decidir se um nome de variável é pronunciável ou não, basta responder a seguinte pergunta: é possível discutir sobre o funcionamento desse trecho de código sem parecer um bando de malucos?
- "Pedro, precisamos alterar a variável dhur da função gendh agora que a empresa abril uma filial na França"
- dhur: data e hora da ultima revisão, uma sugestão melhor seria dataHoraUltimaRevisão
- gendh: gera data e hora, uma sugestão melhor seria geraDataHora
Prefixo de variável membro
Utilizar this/self das linguagens de programação torna a leitura mais simples do que se utilizadas variáveis privadas.
Evite mapeamento mental
O leitor não deve precisar traduzir mentalmente os nomes por outros que eles conhecem, devem ser evitados códigos ou variáveis de uma letra só, a exceção de iteradores i, j ou k, que já é uma tradição. Qualquer um que ler o código deve ser capaz de entende-lo sem um glossário.
Nomes de classes, métodos e funções
- Nomes de classes devem ser substantivos, afinal representam algo (exemplo: Account);
- Nomes de métodos e funções devem ser verbos, afinal executam uma ação.
- Utilizar prefixos get, set e is (exemplos: account.getName, account.setName, account.isCustomer) .
- Quando construtores estiverem sobrecarregados é preferível utilizar factory methods com nomes descritivos e privar os construtores (account.fromNumber(2), account.fromName("João") seriam factoryes para construtores de account).
Selecione uma palavra por conceito
Várias palavras podem significar a mesma coisa, não há problema escolher qualquer uma que faça sentido ao código, mas é importante manter um padrão usando a mesma palavra para um propósito no código todo.
Adicione um contexto significativo
Nome, Rua, número, cidade e estado podem significar alguma coisa quando estão juntas, mas não são tão significativas separadas, então pode-se usar um prefixo nos nomes endereçoNome, endereçoRua... ou criar uma classe abstrata endereço que contenha esses atributos: endereço.Nome, endereço.Rua...
Não adicione contextos desnecessários
Não inicie todas as variáveis de um escopo com a mesma combinação de letras, isso vai atrapalhar o uso do auto-complete da IDE trazendo uma lista quilométrica e vai confundir o leitor.
Não tenha medo de estar atrapalhando os outros desenvolvedores ao renomear variáveis, ninguém decora esses nomes e todos ficarão agradecidos por uma melhora na legibilidade do código.
Oldest comments (0)