Así que al mirar antes, noté algunos comentarios acerca de que los métodos largos son una mala práctica.
No estoy seguro de estar siempre de acuerdo en que los métodos largos son malos (y me gustaría recibir opiniones de otros).
Por ejemplo, tengo algunas vistas de Django que procesan un poco los objetos antes de enviarlos a la vista, un método largo son 350 líneas de código. Tengo mi código escrito para que se ocupe de los parámetros: ordenar / filtrar el conjunto de consultas, luego, poco a poco, se procesa algo en los objetos que ha devuelto mi consulta.
Por lo tanto, el procesamiento es principalmente una agregación condicional, que tiene reglas suficientemente complejas que no se pueden hacer fácilmente en la base de datos, así que tengo algunas variables declaradas fuera del bucle principal y luego las modifico durante el bucle.
variable_1 = 0
variable_2 = 0
for object in queryset :
if object.condition_condition_a and variable_2 > 0 :
variable 1+= 1
.....
...
.
more conditions to alter the variables
return queryset, and context
Entonces, de acuerdo con la teoría, debería factorizar todo el código en métodos más pequeños, de modo que tenga el método de visualización con una longitud máxima de una página.
Sin embargo, después de haber trabajado en varias bases de código en el pasado, a veces encuentro que el código es menos legible, cuando necesita saltar constantemente de un método a otro para descubrir todas las partes del mismo, mientras mantiene el método más externo. tu cabeza.
Encuentro que al tener un método largo que está bien formateado, puedes ver la lógica más fácilmente, ya que no se esconde en los métodos internos.
Podría dividir el código en métodos más pequeños, pero a menudo hay un bucle interno que se usa para dos o tres cosas, por lo que resultaría en un código más complejo, o métodos que no hacen una cosa sino dos o tres (alternativamente, podría repetir bucles internos para cada tarea, pero luego habrá un impacto de rendimiento).
Entonces, ¿existe el caso de que los métodos largos no siempre sean malos? ¿Hay siempre un caso para los métodos de escritura, cuando solo se usarán en un lugar?
ACTUALIZACIÓN: Parece que hice esta pregunta hace más de un año.
Así que he refactorizado el código después de la respuesta (mixta) aquí, lo dividí en métodos. Es una aplicación de Django que recupera conjuntos complejos de objetos relacionados de la base de datos, por lo que el argumento de prueba está fuera (probablemente habría tomado la mayor parte del año crear objetos relevantes para los casos de prueba. Tengo un tipo de "esto se hizo ayer") ambiente de trabajo antes de que alguien se queje). Arreglar errores en esa parte del código es un poco más fácil ahora, pero no de forma masiva.
antes:
#comment 1
bit of (uncomplicated) code 1a
bit of code 2a
#comment 2
bit of code 2a
bit of code 2b
bit of code 2c
#comment 3
bit of code 3
ahora:
method_call_1
method_call_2
method_call_3
def method_1
bit of (uncomplicated) code 1a
bit of code 2a
def method_2
bit of code 2a
bit of code 2b
bit of code 2c
def method_3
bit of code 3