Es bueno dividir el código en funciones y clases para la modularidad/desacoplamiento, pero si lo haces demasiado, obtendrás un código realmente fragmentado que tampoco es bueno.¿Cuál es la regla de oro para cuándo dividir el código en funciones?
¿Cuál es la regla de oro para cuándo dividir el código en funciones?
Realmente depende del tamaño y el alcance de su proyecto.
que tienden a dividir las cosas en funciones cada vez que hay algo repetido, y que la repetición generalizada/abstraída, siguiendo la regla de oro de DRY (No te repitas).
En cuanto a dividir clases, tiendo a seguir el mantra de Programación Orientada a Objetos de aislar lo que es diferente de lo que es diferente, y dividir las clases si una clase implementa más una "idea" teórica grande o entidad .
Pero, sinceramente, si su código es demasiado fragmentado y opaco, debería intentar considerar la refactorización en un enfoque/paradigma diferente.
Probablemente mi propia regla personal es si es más de 2 líneas de longitud, y se hace referencia más de una vez en la misma página (ASP.net), o unas pocas veces repartidas en un par de páginas, que lo haré escribe una función para hacerlo.
Creo que generalmente hay que pensar en una porción de códigos que tienen la posibilidad de ser reutilizados. Viene con experiencia para resolverlo y planificar el futuro.
Me enseñaron que cualquier cosa que hagas más de una vez debería ser una función. Cualquier cosa similar debe tener una clase para padres y, sobre todo, consultar los "estándares" de código fuente dentro de su organización. El último trata principalmente con el formateo.
Tendría cuidado al defender la herencia solo para proporcionar un acceso fácil a las funciones comunes. La composición es mejor. Deje la herencia para expresar las relaciones 'is-a'. –
punto tomado Lauri – bobby
Estoy de acuerdo con las respuestas que se centran en la reutilización y la eliminación de la repetición, pero también creo que la legibilidad es al menos tan importante. Entonces, además de la repetición, buscaría fragmentos de código (clases, funciones, bloques, etc.) que hagan más de una cosa.
Si el nombre asociado con el código no describe lo que hace, entonces ese es un buen momento para refactorizar ese código en unidades que tienen cada uno un single responsibility y un nombre descriptivo. Este separation of concerns ayudará tanto a la reutilización como a la legibilidad.
El código útil puede quedarse por mucho tiempo, por lo que es importante que usted (o, idealmente, alguien más) pueda retroceder y comprender fácilmente el código que se escribió meses o años antes.
Si puedo darle un buen nombre (mejor que el código que sustituye), se convierte en una función
1: segundo concepto es la SRP http://en.wikipedia.org/wiki/Single_responsibility_principle –