Como señalaron las personas, esto mejora la legibilidad. Una persona que lee process_url()
puede ver más claramente cuál es el proceso general para tratar las URL solo con leer algunos nombres de métodos.
El problema es que otras personas pueden pensar que esas funciones son utilizadas por alguna otra parte del código, y si es necesario cambiar algunas de ellas, pueden optar por conservar esas funciones y definir otras nuevas. Esto significa que algún código se vuelve inalcanzable.
Hay varias maneras de lidiar con esto. Primero está la documentación y los comentarios en el código. En segundo lugar, herramientas que proporcionan pruebas de cobertura. En cualquier caso, en gran medida esto depende del lenguaje de programación, estas son algunas de las soluciones que puede aplicar según el lenguaje de programación:
- los lenguajes orientados a objetos pueden permitir definir algunos métodos privados, para garantizar que no se utilicen en ningún otro lado
- los módulos en otros idiomas pueden especificar qué funciones son visibles desde el exterior, etc.
- los lenguajes de muy alto nivel como Python pueden eliminar la necesidad de definir varias funciones porque, de todos modos, serían simples lineas simples
- otros idiomas como Prolog pueden requerir (o sugerir fuertemente) la definición de un nuevo predicado para cada salto condicional.
- en algunos casos es común definir funciones auxiliares dentro de la función que las usa (funciones locales), algunas veces son funciones anónimas (cierres de código), esto es común en las funciones de devolución de llamada de Javascript.
En resumen, dividir en varias funciones suele ser una buena idea en términos de legibilidad. Puede que no sea realmente bueno si las funciones son muy cortas y esto crea el efecto goto
o si los nombres no son realmente descriptivos, en ese caso, leer un código requeriría saltar entre las funciones, lo que puede ser complicado. Sobre su preocupación sobre el alcance y el uso de estas funciones, hay varias formas de tratarlas que dependen del idioma en general.
En general, el mejor consejo es usar el sentido común. Cualquier regla estricta es muy probable que sea incorrecta en algún caso y al final depende de la persona. Yo consideraría esto legible:
process_url = lambda url: dict(re.findall('([^?=&]*)=([^?=&]*)', url))
Personalmente, prefiero un forro, aunque sea ligeramente complejo en lugar de saltar y buscar en varios archivos de código, si me demoran más de tres segundos en encontrar otra parte del código que pueda Ni siquiera sabía qué estaba revisando de todos modos. Las personas que no padecen TDAH pueden preferir más nombres explicativos que puedan recordar, pero al final lo que siempre está haciendo es equilibrar la complejidad en los diferentes niveles de código, líneas, párrafos, funciones, archivos, módulos, etc.
Por lo tanto, la palabra clave es balance . Una función con mil líneas es un infierno para cualquiera que la lea, porque no hay encapsulación y el contexto se vuelve demasiado grande. Una función dividida en mil funciones, cada una de ellas con una línea puede ser peor:
- tiene algunos nombres (que podría haber proporcionado como comentarios en las líneas)
- está (con suerte) eliminando variables globales y no tiene que preocuparse por el estado (con transparencia referencial)
- pero obligas a los lectores a saltar de un lado a otro.
Aquí no hay balas de plata, sino experiencia y equilibrio. En mi humilde opinión, la mejor manera de aprender cómo hacerlo es leer un montón de código escrito por otras personas y analizar por qué es difícil para usted leerlo y cómo hacerlo más legible. Eso proporcionaría una valiosa experiencia.