Estoy obteniendo dos puntos de vista contradictorios sobre esto. Algunas fuentes dicen que debería haber menos métodos para reducir las llamadas a los métodos, pero otra fuente dice que escribir un método más corto es bueno para permitir que el JIT haga la optimización.C#, ¿Escribir método más largo o método más corto?
Entonces, ¿de qué lado es correcto?
La sobrecarga de hacer realmente la llamada al método es inconsecuentemente pequeña en la mayoría de los casos. Nunca debe preocuparse, a menos que pueda identificar claramente un problema en el futuro que requiera una revisión del problema (no lo hará).
Es mucho más importante que su código sea simple, legible, modular, mantenible y modificable. Los métodos deben hacer una cosa, una sola cosa y delegar sub-cosas a otras rutinas. Esto significa que sus métodos deben ser tan cortos como sea posible, pero no más cortos. Verá muchos más beneficios de rendimiento al tener un código que es menos propenso a errores e insectos porque es simple, que al intentar superar al compilador o el tiempo de ejecución.
La fuente que dice que los métodos deben ser largos es mal, en muchos niveles.
Ninguna, debe tener un método relativamente corto para lograr legibilidad.
No existe una regla simple sobre el tamaño de la función. La guía debe ser una función que debe hacer 'una cosa'. Eso es un poco vago, pero se vuelve más fácil con la experiencia. Las funciones pequeñas generalmente conducen a la legibilidad. Los grandes son ocasionalmente necesarios.
Preocuparse por la sobrecarga de las llamadas a los métodos es una optimización prematura.
Como siempre, se trata de encontrar un buen equilibrio. Lo más importante es que el método hace una cosa solo. Los métodos más largos tienden a hacer más de una cosa.
Antes que nada, definitivamente no se debe optimizar el desempeño en el nivel de número de métodos. Lo más probable es que no obtenga ningún beneficio de rendimiento mensurable. Solo si tiene un método que se llama millones de veces, puede ser una idea, pero no comience a optimizarlo antes de que lo necesite.
Debe apegarse a los métodos concisos cortos, que hace una cosa, que hace que la intención del método claro. Esto le dará un código más fácil de leer, que es más fácil de entender y promueve la reutilización del código.
El mejor criterio para guiarlo en los métodos de dimensionamiento es mantenerlos bien comprobables. Si puede (¡y en realidad HACE! -) probar a fondo todos los métodos, es probable que su código sea bastante bueno; si escatima en las pruebas, es probable que su código sea, en el mejor de los casos, mediocre. Si un método es difícil de probar minuciosamente, es probable que ese método sea "demasiado grande": tratar de hacer demasiadas cosas y, por lo tanto, también es más difícil de leer y de mantener (así como una prueba incorrecta y, por lo tanto, un refugio probable para loco).
El costo más importante a considerar cuando se escribe código es la capacidad de mantenimiento. Va a pasar mucho, mucho más tiempo manteniendo una aplicación y solucionando errores de lo que nunca solucionará problemas de rendimiento.
En este caso, el costo casi seguro insignificante de llamar a un método es increíblemente pequeño en comparación con el costo de mantener un método grande y difícil de manejar. Los métodos pequeños y concisos son más fáciles de mantener y comprender. Además, el costo de llamar al método casi con certeza no tendrá un impacto significativo en el rendimiento de su aplicación. Y si lo hace, solo puede afirmar eso mediante el uso de un generador de perfiles. Los desarrolladores son notoriamente malos a la hora de identificar problemas de rendimiento de antemano.
En general, una vez que se identifica un problema de rendimiento, son fáciles de corregir. Hacer un método o, lo que es más importante, una base de código, mantenible es un costo mucho más elevado.
Personalmente, no le temo a los métodos largos, siempre y cuando la persona que los escribe los escriba bien (cada parte de la subtarea separada por 2 líneas nuevas y un bonito comentario precediéndola, etc. Además, la identación es muy importante.) De hecho, muchas veces incluso los prefiero (por ejemplo, al escribir código que hace las cosas en un orden específico con lógica secuencial).
Además, realmente no entiendo por qué dividir un método largo en 100 piezas mejorará la legibilidad (como otros sugieren). Solo lo opuesto. Usted solo terminará saltando por todos lados y guardando pedazos de código en su memoria solo para obtener una imagen completa de lo que está sucediendo en su código. Combine eso con la posible falta de comentarios, nombres de funciones incorrectos, muchos nombres de funciones similares y tiene la receta perfecta para el caos. Además, podría ir al otro extremo al intentar reducir el tamaño de los métodos: crear MUCHAS clases y MUCHAS funciones, cada una de las cuales puede tomar MUCHOS parámetros. No creo que esto mejore la legibilidad tampoco (especialmente para un principiante de un proyecto que no tiene idea de qué hace cada clase/método).
Y la exigencia de que "una función debería hacer 'una cosa'" es muy subjetiva. 'Una cosa' puede ser aumentar una variable por uno hasta hacer una tonelada de trabajo supuestamente por 'lo mismo'.
Mi regla solo es reutilizable: El mismo código no debería aparecer muchas veces en muchos lugares. Si este es el caso, necesita una nueva función. Todo lo demás es solo charla filosófica. En una pregunta de "¿por qué haces que tus métodos sean tan grandes?", Respondo, "¿por qué no si el código es simple?".
(solo mi opinión - vote tanto como desee)