Por algum motivo atualmente é convenção nomear qualquer método com o prefixo handle quando ele é chamado em um evento, tipo chamar de handleClick um método chamado num evento de click, handleChange quando lidamos com o evento change e assim por diante.

Mas advinha?! Isso é o crime do crime!

O nomes dos nossos métodos ficam sem significado, o nome não diz nada sobre a função do método, só é dito quando ele é disparado, não o que ele de fato faz!

Suponhamos que temos que trabalhar em uma loja de roupas e precisamos dar manutenção neste componente, o que acontece quando clico nos botões?

function MyComponent() {

  /.../

  return (
    <>
      <button name="short" onClick={handleClick}> Short </button>
      <button name="medium" onClick={handleClick}> Medium </button>
      <button name="big" onClick={handleClick}> Big </button>
      <button name="bigger" onClick={handleClick}> Bigger </button>
    </>
  )
}

Teria que ler a implementação do handleClick pra poder responder essa pergunta, apenas com a informação atual o máximo que podemos fazer é supor de forma bem branda o que acontece ao clicar no botão, mas não temos quase nenhuma certeza!

Mas fazendo apenas ajustando o nome da função, fica claro o que acontece ao clicar no botão

function MyComponent() {

  /.../

  return (
    <>
      <button name="short" onClick={applySearchFilter}> Short </button>
      <button name="medium" onClick={applySearchFilter}> Medium </button>
      <button name="big" onClick={applySearchFilter}> Big </button>
      <button name="bigger" onClick={applySearchFilter}> Bigger </button>
    </>
  )
}

Com uma simples alteração no nome da função e apenas lendo o return do componente podemos saber o que está acontecendo, sem precisar ir na função, entender a lógica lá pra poder saber o que acontece. O código está claro quanto ao que ele faz, é explícito como deve ser.

📝 Note

Existe apenas um caso que faz algum sentido chamar a função handler de handle, e é quando, em casos muito raros, a função precisa fazer mais de uma coisa. Nesse caso chamar de handle é o meio genérico de chamar o método e, dentro dele, chamamos os 2 ou mais métodos necessários.

Por exemplo, suponhamos que o pessoal de produto acordou, caiu da cama, bateu a cabeça no chão e quer que quando o usuário mudar o filtro de busca o site mude de cor completamente, ai faz sentido usar handleClick

function MyComponent() {
  function handleClick(e) {
    applySearchFilter(e);
    changeSiteColor(e);
  }

  return (
    <>
      <button name="short" onClick={handleClick}> Short </button>
      <button name="medium" onClick={handleClick}> Medium </button>
      <button name="big" onClick={handleClick}> Big </button>
      <button name="bigger" onClick={handleClick}> Bigger </button>
    </>
  )
}

E se nomearem a função de forma errada?

Esse tipo de coisa precisa ser percebida e corrigida o quanto antes, se essa má nomeação te levou ao erro, você tem o dever de ajustar o nome da função para prevenir que futuros devs sejam induzidos ao erro também!

É legal também tirar print do git blame e colocar no grupo da empresa

Reutilização legível

Usando esse método de nomenclatura ainda por cima ganhamos a semântica de poder reutilizar a função usada no evento mantendo a leitura do código limpa!

Suponhamos que nos exemplos anteriores, por algum motivo, outro método precisa chamar a função applySearchFilter

function MyComponent() {
  function applySearchFilter(e) { /.../ }

  function updateSearchText(e) {
      applySearchFilter(e);
  }

  return (
    <>
      /.../
      <button name="short" onClick={applySearchFilter}> Short </button>
      <button name="medium" onClick={applySearchFilter}> Medium </button>
      <button name="big" onClick={applySearchFilter}> Big </button>
      <button name="bigger" onClick={applySearchFilter}> Bigger </button>
    </>
  )
}

Dessa forma podemos ler de forma falada dizendo que "após atualizar o texto de busca o filtro é aplicado" ao invés de dizer "após atualizar o texto de busca lidamos com o click"

Tem uma fala de Grady Booch que eu gosto muito

Um código limpo é simples e direto. Ele é tão bem legível como uma prosa bem escrita.

💡 Tips

• Pra nomear uma função sempre se pergunte: "O que essa função faz?"

📚 References

Vozes da minha cabeça
Clean Code - Uncle Bob