Corrigindo um erro de ortografia no nome de um método

73

Um dos métodos que eu normalmente uso em nossa base de código está incorreto (e me antecedeu).

Isso realmente me irrita não apenas porque está escrito incorretamente, mas, o mais importante, sempre me leva a errar o nome na primeira vez em que o digito (e depois me lembro "Oh, certo, isso deve ser escrito incorretamente ...")

Estou fazendo algumas alterações em relação ao método original. Devo aproveitar a oportunidade para renomear o método em pânico?

refactoring

— Um dois três
fonte

12

Você pode renomear? Se for usado por código que você não controla, justifique a quebra de compatibilidade com versões anteriores.

16

*com erros ortográficos. E você terá que alterá-lo em todos os lugares em que esse método for chamado.

— precisa

2

* erro de ortografia ... ou talvez uma ortografia diferente?

— HorusKol

2

@ JohnP Havia três, agora um está consertado e dois ainda estão incorretos. Por coincidência, combina muito bem com o nome do OP. :)

— Desiludido

3

Não devemos permitir que nada seja derrubado incorretamente!

— Magus

136

Devo aproveitar a oportunidade para renomear o método em pânico?

Absolutamente.

Dito isto, se o seu código foi lançado como uma API, você também deve geralmente deixar o método com erros ortográficos e encaminhar para o método nomeado corretamente (marcando-o como Obsoleto se seu idioma suportar essas coisas).

— Telastyn
fonte

33

A idéia de "encaminhar para o método nomeado corretamente" é simples e brilhante. Link interessante sobre a teoria das janelas quebradas também.

— dev_feed

2

Observe que, se isso faz parte de uma API pública, pode não ser uma alteração compatível com versões anteriores (dependendo do idioma). Isso não é tão improvável quanto pode parecer. Se eu tivesse que herdar de uma API existente com um nome incorreto, eu definitivamente corrigiria isso.

— Voo

10

@voo - eh? Que linguagem tornaria a adição de um novo método (e a alteração da implementação de um para fazer o mesmo comportamento exato) não ser compatível com versões anteriores?

— Telastyn

3

@Telastyn às vezes pode ser complicado adicionar métodos para dizer serviços da web. Alguns clientes recusam-se a alterar WSDLs, por exemplo, se recusam repentinamente a conversar com o servidor. Esse é um problema de implementação no cliente, mas se o cliente é importante, você não quer incomodá-lo e pode muito bem impedir que você altere sua interface.

— jwenting

17

@Telastyn Se o nome do método com erros ortográficos estiver em uma interface (como no tipo de interface usado em Delphi / Java / C #), a adição de uma versão com grafia correta do nome provavelmente interromperá todas as implementações existentes dessa interface.

— Desiludido

52

Há casos em que você deve evitar fazer essas refatorações:

Se o método for usado em uma interface pública. Um exemplo canônico é o erro de ortografia do referenciador no referenciador HTTP , a ortografia incorreta sendo mantida, porque a alteração da ortografia agora teria muitas repercussões.
Se a base de código não for coberta por nenhum teste. Qualquer refatoração deve ser feita no código testado para poder fazer o teste de regressão. Refatorar a base de código que não está sendo testada é particularmente arriscado. Se você tiver muito tempo, comece adicionando testes; se você trabalha com pressão de tempo, correr o risco de introduzir bugs sutis não é a melhor coisa a fazer se você quiser enviar a tempo.
Se o método puder ser usado de maneira incomum , o que torna praticamente impossível seu uso (por meio de Ctrl + F ou de uma ferramenta de refatoração automática). Por exemplo, em C #, um método pode ser chamado por meio do Reflection, tornando a caixa de diálogo Renomear do Visual Studio ineficaz. Em JavaScript, a função chamada inside também eval()é difícil de encontrar. No PHP, variáveis variáveis podem causar problemas.
Se o tamanho do projeto for enorme e o método puder ser usado por outras equipes. Isso é semelhante ao primeiro ponto, ou seja, a interface que você fornece a outras equipes pode ser considerada uma interface pública.
Se você lida com um projeto de vida crítica. As chances são de que o erro de ortografia não seja importante demais para justificar alguns meses de papelada para alterar o nome do método e garantir que ele não faça com que nenhum paciente receba dez vezes a radiação autorizada ou qualquer lançadeira para calcular mal sua velocidade.

Em qualquer outra situação, fique à vontade para renomear o método.

— Arseni Mourzenko
fonte

11

+1 no comentário que menciona Reflexão, ele foi mordido mais de uma vez.

— DaveShaw

33

Se o seu projeto crítico de vida é frágil o suficiente para que a menor refatoração possa matar alguém, é frágil o suficiente para que ninguém confie nele com a própria vida. Como você está confiante de que seu novo recurso ou interface de usuário simplificada não apresentou bugs com risco de vida se você não pode nem renomear um método?

— user2357112

2

Da mesma forma, se um nome de método alterado causa vários meses extras de papelada (em vez de, digamos, ser tratado principalmente pela papelada de todas as outras coisas que estão mudando ao mesmo tempo), o equilíbrio da programação para a papelada é distorcido por várias ordens de magnitude, e é impossível obter grandes melhorias sem alterar o sistema.

— user2357112

8

@ user2357112: Eu nunca disse que a menor refatoração provavelmente mataria alguém. Não se trata de matar alguém, mas de tornar tudo possível para mitigar o risco restante de 0,001% de um bug. Isso requer um perfil formal. Isso requer várias camadas de teste. Isso requer formalismo. Isso proíbe "Eu quero renomear rapidamente esse método, espero que funcione!" comportamento. Projetos críticos à vida usam técnicas que seriam consideradas um completo desperdício de tempo e dinheiro para qualquer aplicativo de negócios. É por isso que eles são tão confiáveis (e caros).

— Arseni Mourzenko

5

@ user2357112: como destacou a MainMa, não se trata de aplicativos de negócios casuais. É sobre um tipo especial de software que é extensivamente testado / verificado. E se o método for chamado por reflexão em algum lugar? E se alguma ferramenta de compilação pré / pós fizer algo com ela? E a documentação? E as outras equipes que o usam? Eles usam reflexão? E se ... A vida real às vezes pode ser bastante complexa. E, às vezes, é melhor deixar um nome de método intocado, em vez de verificar se há alguma conseqüência à prova de balas.

— dagnelies

30

Eu fiz isso alguns meses atrás (por diferentes razões). Os passos que tomei (o idioma era Perl):

Renomeie o método Alias o nome antigo para o novo nome (isso não deve quebrar nenhum código, pois o método pode ser chamado por um ou outro nome).
Informe os outros desenvolvedores sobre a mudança de nome e por quê, dizendo-lhes para usar o novo nome a partir de agora.
Grep a base de código para o nome antigo, corrija quaisquer ocorrências.
Registre qualquer uso do nome antigo (o uso do nome antigo ainda deve funcionar no momento). Corrija esses casos.
Aguarde (enquanto faz o 4.), até que não apareçam mais entradas no log.
Quebre o apelido. Faça um método usando o nome antigo que lança uma exceção fatal com uma mensagem sobre a alteração de nome.
Após algum tempo, remova o método com o nome antigo.

Obviamente, sua milhagem varia.

— Abigail
fonte

Uma melhoria - não confie no grep para encontrar usuários com o nome antigo, faça também o logon no encaminhador.

— Ben Voigt

@BenVoigt Não é isso que o nº 4 faz?

— Bob

6

Uma boa maneira de não quebrar nenhum código existente seria encadear o novo nome do método para o antigo

private void MyNewMethodName()
{
    TheOldMethodName();
}

e marque o método antigo como obsoleto (se o seu idioma suportar isso). Dessa forma, qualquer código existente ainda funcionará e você poderá remover gradualmente todo o antigo erro de ortografia da sua base de código. Eventualmente, você pode até copiar / colar o corpo do método no novo método e excluir o antigo.

/ Edit Como o ivo disse no comentário: Uma coisa ainda melhor a fazer seria mover o código para TheOldMethodNamedentro do MyNewMethodNamee chamar o novo método do antigo. Este também teria a vantagem de ajudar o desenvolvedor a saber onde o código pertence.

— Rémi
fonte

2

Eu concordo com o seu método; Eu faria o mesmo. É o método mais sensato, claro e seguro de refatoração. O que também pode ser uma boa maneira é mover o código do método antigo para o novo método e fazer com que o antigo use o novo método. Quando a base de código está a poucas iterações da linha do tempo, você só precisa remover o método obsoleto antigo.

— Ivo Limmen

11

@IvoLimmen Essa é uma sugestão muito boa. Dessa forma, as pessoas ficam ainda mais interessadas em usar o novo método e isso remove um aviso da chamada obsoleta para o método antigo de dentro do novo. Vou acrescentar isso à minha resposta.

— Rémi 13/06

1

Renomeando o método:

Faça refatoração para que você não tenha mais trabalho do que deseja
Se o seu IDE oferecer suporte à conclusão automática, use-o ao fazer referência a esse método

Essas são duas opções pelas quais você poderia escolher. Eu preferiria o preenchimento automático (por exemplo, IDE Eclipse) e não precisaria digitar o nome do método. Indo para o renomear; apenas descubra o que chama esse método e altere as referências diretas em cada local. A refatoração será sua amiga, mas tenha muito cuidado ao fazê-lo.

— Mushy
fonte

0

Eu geralmente recomendaria sim, renomeá-lo.

Outras respostas aqui listaram boas razões para você não querer renomeá-lo, portanto, se você se encontrar em uma dessas situações, poderá criar um novo método com o nome e a implementação adequados e alterar o método antigo para chamar o novo método . Em seguida, marque o antigo como obsoleto se o seu idioma suportar.

— Brian
fonte