Bom dia a todos.

Lendo alguns exemplos de Restfulie (em especial), vi que a nomeclatura dos controllers, em especial, são até certo ponto minimalista. Nomes curtos e expressivos.

Diante disso, tenho uma curiosidade: o que vocês estabelecem como padrão para usarem nos models? Nomes curtos (e.g. class User, método buscar) ou nomes mais complexos e descritivos, semelhantes aos recomendados para TDD (e.g. class User, método buscarPeloId).

Qual idéia/metodologia vocês usam?

Em testes eu uso o mais claro possivel.

Nos meus modelos também prefiro utilizar nomes de métodos que façam sentido ao ler, mas também tomo cuidado para ser redudando como no caso:

No caso acima o nome do método está redudando já que estamos em um DAO de contato, IMHO o nome do método deveria ser apenas insere() e não insereContato().

Outra caso que você citou é o busca() ou buscaPeloID(). Eu sempre utilizo os parametros como complemento para expressar o método, nomenclaturas dos parametros são bem importantes para a expressividade da assinatura do método.

Sobre o tamanho, eu não me preocupo tanto com isso, me preocupo sim se o nome do método está grande pq ele está fazendo coisas de mais (hora de quebrar em outros metodos).

As vezes a expressividade prejudica a legibilidade, como no caso:

@Test
verificaSePodeHabilitarNovoRegistroPassandoParametroInvalido(){}

acho q tudo deve ser um balanceamento entre expressividade e legibilidade

Oi Anderson,

Pode me linkar os testes para que eu possa ver se eu gostaria de renomea-los? Seria uma grande ajuda.

Em geral, prefiro nomes longos e que digam exatamente o que deveriam fazer, como por exemplo:

Ao inves do que não gosto, que não deixa claro as condições e a situação exata, além de sua expectativa:

Ou ainda outra forma que não gosto, mais direta ainda:

Olá Guilherme.

Não há nada de testes a linkar não hehe
Foi mais uma curiosidade e vontade de colocar esse assunto em debate.

E, também, pelo motivo já citado acima. Eu estava lendo os docs do Restfulie e parei para pensar nisso. Então, percebi que normalmente utilizo nomes bem descritivos em meus modelos. Já nos controles, gosto de nomes mais minimalistas mesmo, ainda mais pelo fato de o mesmo ficar ‘disponível’ para o usuário final dos sistemas. ;)

Abraços!

Gosto de ser expressivo também, usando o junit faço os testes um pouco diferentes mais bem expressivos:

No Calopsita (http://calopsitaproject.org), usamos uma nomenclatura pra JUnit num esquema parecido com esse, Alberto, mas fizemos uma sintaxezinha própria pra permitir trabalhar com objetos mais especializado nesses métodos de suporte:

Esses objetos given, when e then é que contém os métodos chamados e temos alguns tipos de givens, então, pra navegar de um pra outro, os conectivos and, which, in nos ajudam.

Mas com foco na discussão inicial, os testes, gosto de descrever muito bem o que está acontecendo, mas em métodos e classes de produção, prefiro (inconscientemente, acho) nomes o mais curtos possível que digam o que aquilo faz.

Muito bom ver isso, estou sempre procurando ver referenciais para comparar e gostei do que o calopsita faz. Parabéns.

Digo o mesmo Carlos.

É bom ver, através de discussões e exemplos como os expostos aqui, um bom caminho (das pedras) a seguir ;)

Alguém ja uso o JBehave? Eu usei uma vez e achei bem bacana o resultado, pelo eu acho melhor do que o exemplo postado pelo Carlos.
Ler isso dado Que Estou Acessando Como Gerente Da Loja é mais fácil do que ler isso dadoQueEstouAcessandoComoGerenteDaLoja.

Só um ponto, Carlos Alberto:
cuidado para que seus testes não testem coisas demais.
o ideal é que cada método de teste teste somente uma funcionalidade/comportamento/caminho de execução…

olhando para o seu teste não dá pra saber direito se o que vc setou na segunda parte tem efeitos na terceira ou na quarta…

mesmo que vc tenha que repetir alguns comandos (os que descrevem o contexto atual) é bom que as 4 asserções que vc fez no teste sejam 4 testes diferentes

Eu sou a favor do equilíbrio.

Gosto de nomes claros que aumentam a fluência e legibibilidade do código sem ser redundantes.

Cada vez mais tento escrever códigos que se aproximem de algo natural.
Por isso também sou a favor da idéia de utilizar os argumentos do método para ajudar a transmitir sua “Raison d’être”.

Costumo fazer métodos como:

@Pedro e @Lennon.
Usar o parâmetro para expressar o método é bem legal. O único problema é que não se pode fazer sobrecarga com os mesmos argumentos:

Outra coisa que costumo ver muito em códigos e vi aqui também é a falta do infinitivo nos nomes dos métodos:

As vezes ocorre de um nome ser muito grande por conta de um acoplamento também muito grande. Talvez um extract para dividir o método resolveria. É sempre bom utilizar o contexto para expressar suas ações, outras vezes não há para onde correr, ai o jeito é procurar sinônimos curtos e expressivos.

Anderson, eu uso nomes expressivos no model, mas com alguma nomenclatura.
Exemplos:

Os métodos “buscar…()” retornam ou carregam uma instância do objeto. Já os métodos “listar…()” retornam uma lista de objetos.

@wbotelhos

Opa concordo, nesse caso de sobrecarga inválida eu geralmente utilizo o loadByNome(String nome) mesmo, pq ai não tem jeito.

Vinicius, abordagem interessante.

Assim, quem vê já sabe até o tipo que ele retorna. Bem bacana! :D

Boa dica Lucas, vou fazer isso mesmo decompor em testes menores, e gostei muito do que vocês fizeram no calopsita, vou tentar usar um modelo semelhante aqui em meus projetos.

Obrigado a todos.

Nossa, que nomes pequenos! Hehehe. Eu sempre tento passar o máximo da funcionalidade do método no nome. Algo do tipo:
1 calcularValorTotalDaVendaDeAcordoComValoresUnitarios()
Só de ler já cansa! Vocês acham muito cavalar? Eu acho que sim… De fato, eu preciso aprender a melhorar essa parte de escrita.

Uma coisa que comecei a fazer de uns tempos pra cá, mesmo colocando nomes significativos nos métodos é usar JavaDoc. Existem algumas classes *Utils que não tenho a chance de mudar o nome, então coloquei JavaDoc (são métodos com descrição suficiente, mas eu colocaria outro nome). Vocês apoiam o uso do JavaDoc? Lendo o livro Clean Code, eu acho que existe uma certa aversão ao comentário, mas acho que existem casos em que é interessante o uso do mesmo (nessas classes *Utils, por exemplo, que não tenho a oportunidade de mudar o nome do método… Não vejo outro jetio de facilitar a vida dos programadores que usam essas *Utils).

nomes de métodos devem descrever o que eles fazem, e não como eles fazem. Assim você consegue trabalhar voltado à interface e não à implementação.

Qto a usar javadocs, o problema é que documentação está sempre desatualizada, vc não pode depender disso na sua aplicação. O ideal é que as classes e os métodos sejam expressivos o suficiente para vc não precisar da documentação para usar.

Lucas, eu concordo com você. É muito mais saudável e interessante fazer da maneira como você falou.

Mas vamos supor uma situação… Por algum motivo (seja lá qual for), o cliente quer que apareçam diversos valores de uma venda na tela. Baseado nos preços unitários brutos (ou seja, sem desconto), com desconto, com desconto na venda de forma geral, com acréscimo dependendo de um cálculo de juros, e por aí vai. Eu teria que criar o método que falei, deixar público para apresentar o valor calculado na tela e ainda, usar ele em um outro método de cálculo (calcular o valor total bruto e depois o valor total da venda com base em um desconto geral).

Teria uma maneira mais fácil de escrever o nome como disse? Eu não poderia deixar simplesmente
1 calcularValorTotalDaVenda() porque pode ser muito ambíguo (ou generalizado), entende? Poderia me dar a sua opinião nesse ponto?