Qual é a nomenclatura ideal para os nosso métodos?
- Compartilhar
-
- |
Marcar como favorito
Favoritos
Uma boa prática é sempre analisar projetos open source e comparar com a forma que trabalhamos, com tais comparações conseguimos absorver conhecimento e experiência que pode ser útil nos nosso projetos, recentemente Anderson Fraga, no fórum Tectura, iniciou uma discussão onde ele faz um questionamento familiar para muitos desenvolvedores, ele comparou a declaração de métodos e classes do projeto Restfulie e viu que no projeto foi usado nomes curtos e expressivos.
Diante disso iniciou-se um questionamento sobre que nomenclatura usar, vejam a pergunta feita pelo Anderson:
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?
A discussão está bem animada e inicialmente pendeu para o lado dos testes, Geraldo Ferraz destacou um ponto importante:
As vezes a expressividade prejudica a legibilidade, como no caso:
@TestverificaSePodeHabilitarNovoRegistroPassandoParametroInvalido(){}
acho q tudo deve ser um balanceamento entre expressividade e legibilidade
Guilherme Silveira, destacou: "Em geral, prefiro nomes longos e que digam exatamente o que deveriam fazer", o exemplo dado por ele foi:
it "deveria enviar um email caso ocorra um erro" doend
O exemplo dado por Guilherme é um caso de testes de unidade escrito em Ruby utilizando o framework de testes RSpec. Para os programadores Ruby, criar testes com nomes expressivos é uma tarefa relativamente fácil dado que os frameworks de testes facilitam ajudam muito. Mas e com Java? Carlos Alberto comentou dizendo que utilizando JUnit também é possível criar testes bem expressivos, o exemplo dado foi:
public class GerenciamentoClientesManagedBeanTest {@Test public void filtrandoClientes(){dadoQueEstouAcessandoComoGerenteDaLoja();eEstouGerenciandoMeusClientes();ePossuoClientesCadastrados();quandoInformarCriteriosDeBusca();eSolicitarPesquisaPorClientes();oSistemaDeveriaApresentarAListaDeClientes();masSeEuNaoTiverClientesParaOsCriteriosInformados();eSolicitarPesquisaPorClientes();oSistemaDeveriaExibirMensagem("Não a Clientes para os critérios informados");masSeAlgumCampoDoCriterioDeBuscaFoiInformadoIncorretamente();eSolicitarPesquisaPorClientes();oSistemaDeveriaEmitirMensagem("Informe Critérios de busca corretamente");masSeEuEstiverComAlgumErroNoSistemaDeBuscasPorClientes();eSolicitarPesquisaPorClientes();oSistemaDeveriaExibirMensagem("Erro no sistema, não foi possível efetuar busca");oSistemaDeveriaLogarOErroNoLog();}}
Uma outra estratégia utilizada por Cecília Fernandes no projeto Calopsita, também chamou muito a atenção, usando a estrutura do JUnit e Fluent Interfaces, ela utilizou um esquema de modelo de programação compondo métodos que chamou bastante a atenção de todos, vejam a implementação dela:
@Testpublic void addACardInAnIteration() {given.thereIsAnUserNamed("sergio").and().thereIsAProjectNamed("IEs4Linux").ownedBy("sergio").withACardNamed("support IE8").planningCard().whichDescriptionIs("IE8 must be supported").and().withAnIterationWhichGoalIs("new release").and().iAmLoggedInAs("sergio");when.iOpenProjectPageOf("IEs4Linux").and().iOpenThePageOfIterationWithGoal("new release").and().iAddTheCard("support IE8").inThisIteration();then.theCard("support IE8").appearsOnList("iteration_cards");}
Complementando a discussão Guilherme Silveira, deu uma sugestão muito boa, citando o que Lucas Cavalcanti disse:
Como a sugestão que o Lucas deu, componha um comportamento longo por diversos comportamentos menores.Existem diversos padrões para fazer isso como neste post do blog da Caelum.
A tendência que temos observado foi a sugestão de usos de nomes curtos usando composição para descrever comportamentos mais complexos, um dos gurus do desenvolvimento de software, Martin Flower fala exatamente sobre isso e, em um de seus artigos sobre fluent interfaces, cita que o uso de tal conceito, contribui para a criação de uma API que pode compor comportamentos complexo com base em comportamentos mais simples. Reparem no projeto Calopsita citado neste artigo, ele usa uma abordagem semelhante, ficando fácil entender o que o software está fazendo apenas lendo os métodos invocados. Com o uso dos operadores lógicos, vimos como pode ser composto o comportamento aumentando as funcionalidades do software sem aumentar a complexidade, basta reparar que uma composição assim significa mais do que métodos encadeados, significa uma transmissão de conhecimento de negócio através do código.
O ser humano normalmente divide uma coisa complexa para torná-la mais fácil de ser entendida, ao desenvolver pense nos exemplos apresentados acima, e procure tentar incorporar isso ao seu desenvolvimento assim você tem apenas a ganhar.
Avalie esse artigo
- Revisão do Editor
- Ação do Editor Chefe
Submeter
Submeter
Patrocinador relacionado
Red Hat Forum São Paulo 2016: Descubra o poder da colaboração, rumo à transformação digital. Saiba mais
Olá visitante
Você precisa cadastrar-se no InfoQ Brasil ou Login para enviar comentários. Há muitas vantagens em se cadastrar.Obtenha o máximo da experiência do InfoQ Brasil.
Dê sua opinião
Comentários da comunidade
Interessante...
by
Mayck Xavier
Posted
Desprenda-se de convenções de nomenclatura em nomes de testes
by
Prodis a.k.a. Fernando Hamasak...
Posted
Interessante...
by
Mayck Xavier
Parei pra pensar nesse assunto há algumas semanas atrás. Meus métodos estavam ficando com nomes bastante grandes, e como o projeto também é grande, depois de algum tempo me deparei com vários métodos fazendo a mesma coisa.
Achei muito interessante também o modo como a Cecília escreveu os métodos. Tentarei utilizar esse modo sempre que possível.
Achei muito interessante também o modo como a Cecília escreveu os métodos. Tentarei utilizar esse modo sempre que possível.
Desprenda-se de convenções de nomenclatura em nomes de testes
by
Prodis a.k.a. Fernando Hamasak...
Acredito que o nome de métodos de testes precisam ser bem expressivos, para qualquer um bater o olho e já saber do que se trata o teste. Uma alternativa para melhorar a visibilidade de nomes de métodos de testes longos é não utilizar a convenção de nomenclatura de métodos de Java ou C#.
No exemplo do Geraldo Ferraz, o nome do método de teste poderia ser escrito assim:
Há quase um ano atrás escrevi a respeito no meu blog:
prodis.pro.br/2009/11/21/desprenda-se-de-conven...
No exemplo do Geraldo Ferraz, o nome do método de teste poderia ser escrito assim:
@Test
verifica_se_pode_habilitar_novo_registro_passando_parametro_invalido(){}
Há quase um ano atrás escrevi a respeito no meu blog:
prodis.pro.br/2009/11/21/desprenda-se-de-conven...
Links patrocinados
