¿Cuándo debería romper una función?

Question

Es prudente dividir una función larga en funciones principales y auxiliares.

Sé que el exterior del módulo solo se llamará función principal, pero su larga duración puede resultar intimidante.

Los libros de texto limitan el número de líneas, pero creo que esto es demasiado rígido.

P.S. Estoy programando en Python y necesito procesar mensajes entrantes. La función devuelve una tupla que contiene el mensaje pero en los tipos de datos internos de Python. Para que pueda ver código algo independiente para cada tipo de mensaje.

Duplicar Pregunta

When is a function too long?

Answer 1

creo que es necesario ir sobre esto desde el otro extremo del problema. Piense de abajo hacia arriba. Identifique pequeñas unidades de trabajo, tan pequeñas como sea posible, y comience a componer su código de esa manera. Solo se encontrará con problemas de código de spaghetti cuando codifique de arriba hacia abajo y no mantenga un enfoque estructurado.

Si ya tiene código de spaghetti y necesita refactorizar, casi tiene que comenzar de nuevo. Probablemente sea más trabajo romper el código de spaghetti existente que reescribirlo, y el resultado puede no ser tan bueno.

No creo que también deba haber un número difícil para las líneas de código en un método, pero el código bien escrito no tiene métodos con más de 5 a 10 líneas en las capas inferiores, y de 20 a 30 líneas en la lógica de negocios. Para darte algún tipo de métrica.

Answer 2

Una buena regla general es que si no cabe en una sola pantalla, vale la pena pensar sobre dividirlo. Pero solo si tiene sentido dividirlo, algunas funciones largas son perfectamente legibles y no tiene sentido dividirlas servilmente en funciones múltiples por el solo hecho de hacerlo.

Answer 3

No soy un gran fan de romper una función en múltiples funciones innecesariamente. No es algo difícil y rápido: si hay cosas que parecen unidades lógicas distintas, entonces, por supuesto, divídalas y piense en ellas por separado. Pero no solo rompa las cosas por el bien de alguna directriz como "una página por función" o "N líneas por función".

Answer 4

Estuve hablando de esto recientemente con un amigo. Sugirió refactorizar para separar las preocupaciones y debo decir que tengo que estar de acuerdo. Es decir, una función debería hacer una cosa, si hace más de una cosa, divídala. Si no, déjenlo estar juntos, no tiene sentido dividir una función, solo para que oscurezca el significado. ¡Después de todo, una función es un bloque de código que hace una sola cosa!

Answer 5

El límite en términos de número de líneas a menudo no es práctico porque no tiene en cuenta la legibilidad. Es mejor tratar de separar los grupos de líneas de código que tienen solo unas pocas entradas y solo unas pocas salidas y hacer de esto una función separada. No siempre es posible, entonces a menudo es mejor simplemente dejar el código tal como está y no refactorizar por el bien de refactorizar.

Answer 6

Personalmente rompo una función si guarda el total de líneas o el tiempo de procesamiento total.

si sólo se ejecutan una vez por el ayudante principal función no molesto

Answer 7

El punto es que en principio es mejor tener funciones especializadas. Pero donde uno establece el límite depende mucho de 1) el estilo de programación "habitual" en ciertos idiomas. (se puede observar que los lenguajes orientados a objetos tienden a procedimientos más cortos que digamos C o similares 2) depende de su forma de programar. Cada límite difícil debe ser cuestionado. EN MI HUMILDE OPINIÓN. En general, probablemente habrá una distribución "natural" de los programas 3) Creo que lo que hay que tener en cuenta es que una función debe realizar una determinada tarea, por ejemplo, alguna función para analizarla suele ser mucho más larga que una función que solo establece algunos campo en una estructura. O volviendo simplemente considere cómo se puede ver un ciclo de eventos en la API de Windows. De modo que todo sugiere que puede haber buenas razones para los métodos largos ...

Answer 8

Si hay un código independiente (en su caso, detalles para cada tipo de mensaje) esas áreas deberían estar divididas.

Answer 9

El tamaño no importa. Juzgadme por mi tamaño, ¿verdad? - Yoda

Sus principales preocupaciones son la legibilidad, simplicidad y facilidad de mantenimiento. Un buen indicador es si necesita escribir comentarios para explicar una sección de una función, entonces esa sección es un buen candidato para una función separada.

Answer 10

Si no lo escribió y ya está en producción: ¡NUNCA! Si lo rompes, es probable que lo rompas, es así de simple.

Si lo está escribiendo y no está seguro, la pantalla rige las manzanas como han dicho otros.

Answer 11

Hay muchas razones para romper una función larga en sus piezas constituyentes. Lo más importante es:

• legibilidad
• mantenimiento
• la claridad del código/intención

Algunas funciones simples no puede ser roto en pedazos más pequeños sin afectar negativamente a los objetivos enumerados, así que no hay hardware regla rápida.

Answer 12

Nunca escriba una función que, cuando se imprima en papel continuo, sea más alta que usted.

Answer 13

Bueno, ya estoy codificando en Python, así que tengo la libertad de escribir funciones dentro de funciones, a diferencia de C, C++ o Java. Esto siento que es una mejor opción.

Answer 14

Me gusta la regla empírica de que debe salir de la subfunción si puede pensar en un buen nombre de dominio para él.

Cuando alguien puede entender la función de nivel superior sin tener necesariamente que buscar la definición de la subfunción, es probable que haya obtenido una ganancia neta. (Pero cuando lo desglosas demasiado, tus nombres comienzan a referirse a tus artefactos de implementación en lugar del dominio)