¿Cuánto tiempo deberían ser las funciones/métodos en promedio?

Question

Todos hemos leído métodos o funciones excesivamente largos, donde sus ojos terminan sangrando cuando alcanza la declaración de return. También hemos visto esas funciones de una sola línea que parecen inútiles ...

Solo quería preguntar: ¿cuál cree que es la mejor duración promedio para una función/método? Teniendo en cuenta que cada idioma tiene sus propias formas, puede especificar a cuál se refiere en su respuesta. Gracias!

Answer 1

No tiene sentido hablar de "longitud de función promedio". Tienes que usar la regla del pulgar. La función/método debe tener una funcionalidad muy precisa, que debería estar representada por su nombre. Si no puede definir "qué es lo que hace" en su nombre, debe dividirlo. Pero su duración puede variar, ya que algunas tareas muy definidas requieren una cantidad bastante considerable de código.

Y como ha dicho, observar algunas funciones hace que sus ojos sangren. Si sangran, algo anda mal con la función;)

Answer 2

Métodos más cortos con una multitud de otras llamadas a métodos solo para reducir el código en un método particular no significa necesariamente un método "mejor".

Lo que importa no es la longitud, sino la complejidad, legibilidad, usabilidad y escalabilidad del método, y si el código se puede refactorizar en una versión más simple, fácil de leer y menos compleja.

Answer 3

Como dijo Abraham Lincoln cuando se le preguntó cuánto tiempo debe durar la pierna de un hombre, "lo suficiente como para llegar al suelo".

Cada función/método será diferente.

Answer 4

Para mí es muy difícil si una función es más larga que una página impresa. Tampoco me gusta envolver la línea en una impresión. ¿Esto me hace anticuado o le doy mi edad a la basura? ¿Código de impresión?

También diría que si el nombre de una función llamada dentro de mi código no me dice qué función tiene, a menudo es más engorroso saltar varias funciones para averiguar qué se está haciendo. Eso me recuerda los buenos días de COBOL, donde imprimimos código, lo extendimos en el pasillo y cuatro tipos intentaban seguir a todos los GOTO. (Ahora usted definitivamente sabe que he estado por un tiempo.)

Por lo tanto, es un equilibrio entre la longitud y las buenas convenciones de nomenclatura.

Answer 5

Tratando de definir una longitud de método promedio simplemente por el hecho de hacerlo, es como decir que más líneas de código equivalen a una mejor productividad.

La longitud del método es un número sin sentido. Mide la calidad de un método por su especificidad, eficiencia, robustez y legibilidad; no cuántas líneas hay El número de líneas se vuelve aún más insignificante cuando se consideran diferentes estilos de codificación: a algunas personas les gusta tener un montón de espacio en blanco.

Si realmente desea una pauta, suponga automáticamente que cualquier método que tenga más de una página de desplazamiento o dos (según su resolución) es probablemente demasiado largo.

Answer 6

Una función nunca debe ser más larga que una pantalla.

Las funciones deben ser tan largas como su capacidad de atención, de modo que sea posible mantener todo el significado de la misma en su cabeza. El objetivo debe ser expresar la solución de un problema lo más claramente posible.

Tener una regla de oro sobre la longitud máxima es una buena idea, ya que le da una buena indicación de cuándo es posible que no haya alcanzado la suficiente claridad. En mi opinión, puede estar bastante seguro de que algo más que una pantalla no es lo suficientemente claro, así que lo uso como regla general, pero me esfuerzo por hacer que las funciones sean lo más cortas y sucintas posibles.

Las funciones de una línea son perfectamente aceptables si hacen que el código sea más claro, es decir, si el código en él ya no lee, obviamente, lo que hace la función.

Answer 7

La complejidad encapsulante es una de las funciones más importantes de las funciones. Le dice al lector que este fragmento de código no puede tener nada que ver con ese fragmento de código, excepto a través de los valores de parámetro/resultado. La complejidad es también la razón por la que generalmente se deben evitar los efectos secundarios.

Naturalmente, las funciones pequeñas son más fáciles de leer, pero si no hay complejidad, p. estableciendo 200 opciones en un objeto de configuración, luego, por supuesto, tiene una función con 200 líneas.

Las funciones de división con baja complejidad pueden aumentar la legibilidad para esa función, pero también aumentará la complejidad global, un poco.

Answer 8

No es tanto la longitud lo que hace una buena implementación del método. La longitud es solo un aspecto entre otros al juzgar la calidad de la implementación de un método:

• Nivel de abstracción: El código en un método debe mantener un nivel homogéneo de abstracción. Quiero decir, puede hacer girar la cabeza si tienes que leer un método con llamadas de muy alto nivel rociadas entre bloques que hacen cambios básicos de bits, procesamiento de cadenas, etc. Al seguir esta regla, eliminas las distracciones para aquellos que intentan captar método lo hace.
• Formateo: El código siempre se debe formatear para optimizar la legibilidad. Cuando agrega un bloque a un método existente, lo alinea con el código correspondiente. Coloque líneas vacías entre bloques conectados semánticamente. Respetar las convenciones de codificación del equipo.
• Comentarios: Sé reacio a comentar qué hace tu código. Eso ya está escrito en código. Si agrega comentarios, concéntrese en por qué está hecho de esta manera.
• Enfoque: Un método debe enfocarse en una tarea específica. Debería poder describir la implementación en una oración resumida.
• Longitud: sea reacio a hacer un método más largo que una página de monitor.

¿Algún otro criterio de calidad que eché de menos?

Answer 9

Mi regla es: Debería ser obvio por inspección breve (digamos, 30 segundos o menos) que el nombre de la función corresponde a su implementación, suponiendo que las funciones que utiliza tienen implementaciones que corresponden a sus nombres.

Prácticamente, esto significa que mis funciones son bastante cortas. Algunos de ellos son definiciones simples.Como ejemplo patológica:

int AdditiveInverse(int x) { return Negate(x); } 

Si AdditiveInverse y negar son conceptos distintos en mi cabeza, y apenas llegan a coincidir en el mundo real. No hay nada malo con una función pequeñita si introduce un nuevo concepto.

He encontrado que esta regla de oro es más fácil de lograr con un estilo de programación bastante alto. La gestión de la memoria, el paso de índices por separado, etc. obstaculizan la viabilidad de esto. Encuentro que los lenguajes funcionales son especialmente favorables para este estilo: es una guía irrompible para mí cuando escribo Haskell, y una heurística flexible cuando escribo C#.

Answer 10

Creo que los chicos de Object Mentor han pensado en este tema por un tiempo. Tienen a similar question posted some years ago.

Puedes echar un vistazo a esta gran charla, Clean Code III: Functions.

Answer 11

Prefieren las funciones pequeñas y enfocadas.

Reconocemos que las funciones largas a veces son apropiadas, por lo que no se establece ningún límite en la longitud de las funciones. Si una función excede unas 40 líneas, piense si se puede dividir sin dañar la estructura del programa.

Incluso si su función larga funciona perfectamente ahora, alguien que la modifique en unos pocos meses puede agregar un nuevo comportamiento. Esto podría provocar errores difíciles de encontrar. Mantener sus funciones cortas y simples hace que sea más fácil para otras personas leer y modificar su código.

Puede encontrar funciones largas y complicadas al trabajar con algún código. No se deje intimidar por la modificación del código existente: si el trabajo con dicha función resulta ser difícil, encuentra que los errores son difíciles de depurar, o si desea utilizar una parte en diferentes contextos, considere dividir la función en más pequeña y piezas más manejables.

Source

A pesar de que estoy de acuerdo con esto, yo creo que usted debe escribir funciones que son atómicas. Esto significa que: debe escribir funciones lo más pequeñas posible, manteniendo un nombre de función específico. Pero no te vuelvas loco con esto porque puedes terminar con un montón de funciones que son solo una línea.

También creo que al escribir funciones no debe tener muchas líneas nuevas vacías para especificar un bloque de código que hace algo más. Si tiene una nueva línea cada 30 líneas, entonces, tal vez, estas 30 líneas pueden formar una nueva función. O tal vez no. Quizás estas 30 líneas son tan específicas para el propósito del programa que no puedes usarlo en otro lugar, en otro programa.

Piense en el futuro: cree funciones que pueda usar en sus otros proyectos también. Crea funciones genéricas. Entonces, cuando escribes funciones, intenta hacerlas genéricas, pero no demasiado, porque a veces puede tomarte mucho tiempo hacerlas genéricas y tienes un programa para terminar, ¿no? Simplemente manténgala simple como sugiere la guía de estilo de codificación de Google.