Como as pessoas apontaram, isso melhora a legibilidade. Uma pessoa lendo process_url()
pode ver com mais clareza qual é o processo geral para lidar com URLs apenas lendo alguns nomes de métodos.
O problema é que outras pessoas podem pensar que essas funções são usadas por alguma outra parte do código, e se algumas delas precisam ser alteradas, elas podem optar por preservar essas funções e definir novas. Isso significa que algum código fica inacessível.
Existem várias maneiras de lidar com isso. A primeira é a documentação e comentários no código. Em segundo lugar, ferramentas que fornecem testes de cobertura. Em qualquer caso, em grande parte isso depende da linguagem de programação, estas são algumas das soluções que você pode aplicar, dependendo da linguagem de programação:
- linguagens orientadas a objetos podem permitir definir alguns métodos privados, para garantir que eles não sejam usados em outros lugares
- módulos em outros idiomas podem especificar quais funções são visíveis de fora, etc.
- linguagens de alto nível, como o Python, podem eliminar a necessidade de definir várias funções, porque, de qualquer maneira, elas seriam simples para forros.
- outras linguagens como o Prolog podem exigir (ou sugerir strongmente) a definição de um novo predicado para cada salto condicional.
- em alguns casos é comum definir funções auxiliares dentro da função que as utiliza (funções locais), às vezes são funções anônimas (fechamento de código), isso é comum em funções de callback Javascript.
Portanto, em resumo, a divisão em várias funções geralmente é uma boa ideia em termos de legibilidade. Pode não ser realmente bom se as funções forem muito curtas e isso criar o efeito goto
ou se os nomes não forem realmente descritivos; nesse caso, a leitura de algum código exigiria saltos entre funções, o que pode ser confuso. Sobre a sua preocupação com o escopo e o uso dessas funções, existem várias maneiras de lidar com isso que dependem do idioma geral.
Em geral, o melhor conselho é usar o bom senso. Qualquer regra estrita é muito provável que esteja errada em alguns casos e no final depende da pessoa. Eu consideraria isso legível:
process_url = lambda url: dict(re.findall('([^?=&]*)=([^?=&]*)', url))
Pessoalmente eu prefiro um forro, mesmo que seja um pouco complexo, em vez de saltar e procurar em vários arquivos de código, se eu demorar mais de três segundos para encontrar alguma outra parte do código que eu possa nem sei o que eu estava checando de qualquer maneira. Pessoas que não sofrem de TDAH podem preferir nomes mais explicativos que possam se lembrar, mas no final o que você está fazendo é equilibrar a complexidade nos diferentes níveis do código, linhas, parágrafos, funções, arquivos, módulos, etc.
Portanto, a palavra-chave é equilíbrio . Uma função com mil linhas é um inferno para quem lê, porque não há encapsulamento e o contexto se torna muito grande. Uma função dividida em mil funções, cada uma delas com uma linha, pode ser pior:
- você tem alguns nomes (que você poderia ter fornecido como comentários nas linhas)
- você está (esperançosamente) eliminando variáveis globais e não precisa se preocupar com o estado (ter transparência referencial)
- mas você força os leitores a pular para frente e para trás.
Portanto, não há balas de prata aqui, mas experiência e equilíbrio. IMHO a melhor maneira de aprender como fazer isso é ler um monte de código escrito por outras pessoas analisando por que é difícil para você lê-lo e como torná-lo mais legível. Isso proporcionaria uma valiosa experiência.