Legibilidade do código - Nomes significativos
Desde um pouco antes de minha passagem pela Austrália tenho me dedicado a estudar sobre código e formas de codificar. Melhores e piores técnicas. Na época que passei na Austrália essa dedicação foi amplificada, pois como não estava trabalhando e nem a procura de um emprego passei muito tempo apenas lendo a respeito e aplicando algumas técnicas em códigos pessoais.
Se você ainda não teve uma experiência como esta, você é uma pessoa de sorte, mas em alguns casos você é obrigado a trabalhar com a restrição de oito caracteres para nomes. Essa “lei” se aplica para banco de dados antigos que não evoluíram.
Mas isso não quer dizer que o seu código (Java, C#, Ruby….) deva seguir este modelo. Os nomes das variáveis, métodos devem ser ao menos significativos.
Veja o seguinte trecho de código:
Este é apensa um exemplo, mas tais variáveis não dizem nada, absolutamente nada sobre a intenção das mesmas. Além do mais, você como um programador deve codificar mentalmente o que significa as variáveis cor e pal dentro do contexto. Agora leia o código a baixo:
Não é mais simples? Foi necessário alguma decodificação mental a respeito da intenção das variáveis?
Outra regra muito fácil aprendida na faculdade é de que o nomes para métodos devem ser verbos, expressando uma ação. Como por exemplo: get / set / is / do…..
Mas e com relação a construtores? Estes não são nada próximos de amigáveis ou mesmo significativos.
Uma boa saída é criar métodos estáticos dentro da própria classe informando o motivo para aquele construtor estático, por exemplo:
Este é um exemplo muito pequeno e sem nenhum contexto. Ainda neste código o nome do método construtor createComplete poderia ser renomeado apenas para create, caso existisse uma convenção em toda a aplicação de que o método chamado create precise de todos os parâmetros do objeto para ser criados.
Uma outra alternativa seria criar um construtor static ao invés de informar o parâmetro faltante - state - que não é algo muito legível, utilizar um contexto para esta criação, como por exemplo: createForSelect, sendo utilizado para a criação de um objeto City para ser utilizado em um campo html select.
Nomes Significativos.
Se você ainda não teve uma experiência como esta, você é uma pessoa de sorte, mas em alguns casos você é obrigado a trabalhar com a restrição de oito caracteres para nomes. Essa “lei” se aplica para banco de dados antigos que não evoluíram.
Mas isso não quer dizer que o seu código (Java, C#, Ruby….) deva seguir este modelo. Os nomes das variáveis, métodos devem ser ao menos significativos.
Veja o seguinte trecho de código:
Este é apensa um exemplo, mas tais variáveis não dizem nada, absolutamente nada sobre a intenção das mesmas. Além do mais, você como um programador deve codificar mentalmente o que significa as variáveis cor e pal dentro do contexto. Agora leia o código a baixo:
Não é mais simples? Foi necessário alguma decodificação mental a respeito da intenção das variáveis?
Nomes de Métodos e Construtores.
Outra regra muito fácil aprendida na faculdade é de que o nomes para métodos devem ser verbos, expressando uma ação. Como por exemplo: get / set / is / do…..
Mas e com relação a construtores? Estes não são nada próximos de amigáveis ou mesmo significativos.
Uma boa saída é criar métodos estáticos dentro da própria classe informando o motivo para aquele construtor estático, por exemplo:
Este é um exemplo muito pequeno e sem nenhum contexto. Ainda neste código o nome do método construtor createComplete poderia ser renomeado apenas para create, caso existisse uma convenção em toda a aplicação de que o método chamado create precise de todos os parâmetros do objeto para ser criados.
Uma outra alternativa seria criar um construtor static ao invés de informar o parâmetro faltante - state - que não é algo muito legível, utilizar um contexto para esta criação, como por exemplo: createForSelect, sendo utilizado para a criação de um objeto City para ser utilizado em um campo html select.