Escribir rutinas de alta calidad
Cuando programamos, la rutina (método o función), suele ser uno de los bloques más importante de procesamiento de instrucciones con el que solemos trabajar. En programación orientada a objetos el comportamiento de dichos objetos viene determinado por la implementación de los métodos que definen una clase. Por este motivo, porque el comportamiento de nuestra aplicación está basado en el contenido de todos sus métodos debemos prestarles la máxima atención en su desarrollo.
1. Buenas razones para crear una rutina
Reducir complejidad
Este es uno de los motivos más importante. Crear una rutina para ocultar una implementación de manera que no necesitemos pensar en ella. Únicamente será en el momento en el que la escribamos cuando necesitemos pensar en su contenido. Una vez hecho, deberíamos ser capaces de olvidar los detalles de implementación de la misma y usarla sin conocer ninguna especificación sobre como funciona.
Existen otras razones relacionadas como por ejemplo minimizar el tamaño del código o mejorar la mantenibilidad pero la reducción de complejidad que nos aporta el poder de la abstracción que nos pueden proporcionar es fundamental para comprender aplicaciones complejas.
Introducir un intermediario con un nivel de abstracción comprensible
Cuando tengamos una sección de código compleja en vez de leer sentencia a sentencia, podríamos extraer dicha sección a una rutina con un nombre semántico que revele la intención del mismo con exactitud. Hacer esto es la mejor manera de documentar su propósito además de hacer el código más fácil de entender reduciendo la complejidad.
Evitar código duplicado
Crear una función es la razón más popular entre los programadores para evitar código duplicado. Un mismo código en distintas partes de la aplicación podría llevarse a una rutina con una versión común. Con el código en un único lugar no solo tendremos menos espacio ocupado sino que además tendremos un único punto de verdad para una acción y las futuras modificaciones sobre el mismo únicamente se harán en un sitio.
Estas son las tres razones más importantes, aunque existen otras derivadas de las anteriores como por ejemplo: aislar la complejidad, ocultar datos globales, crear puntos centrales de control, facilitar la reutilización de código, mejorar la portabilidad…etc.
2. Elegir un buen nombre para la rutina
El naming, de forma general y como ya he comentado muchas veces, es una de las tareas más complicadas e importantes en el desarrollo de software. En el contexto de las rutinas esto se vuelve más crítico aún porque en el nombre de las mismas está especificado el comportamiento de nuestros objetos y en definitiva de nuestra aplicación. Un buen nombre para una función o método tiene las siguientes características:
Describe todo lo que la rutina hace
El nombre tiene que revelar la intención claramente. El programador debe ser capaz de comprender su propósito con leer únicamente su firma. De modo general, el nombre estará compuesto por un “verbo + objeto”. Como hemos dicho anteriormente, las rutinas contienen el comportamiento de nuestros objetos así que no hay mejor manera de nombrarlas que con un verbo que exprese lo que hacen y además, el objeto o artefacto sobre el cual actúan.
Evitar nombres compuestos
Los nombres compuestos suelen indicar que se está realizando más de una operación, lo cual hace que estemos violando el Principio de Responsabilidad Única.
Evitar los nombres sin sentido, ‘vagos’ o ‘flojos’
Algunos verbos son ‘vagos’ para expresar lo que realmente hace una rutina. Usar en su nombre verbos como handleCalculation(), performServices(), outputUser(), processInput() … no nos dan una idea clara de que están haciendo realmente. Utilizarlos puede indicar que no tenemos muy clara la responsabilidad de la rutina por lo que tendremos que aclarar antes que hace realmente.
Evitar la sobrecualificación
Es bastante común utilizar sufijos o prefijos al pensar en el nombre de una rutina. La mayoría de las veces sobran ya que el contexto o la propia clase en la que se encuentren le dan sentido al nombre. En programación orientada a objetos, la llamada a la rutina ya incluye la clase que la contiene. Por ejemplo, si tenemos una clase Invoice() no tiene mucho sentido tener un método printInvoide(), ya que está claro que nos referimos a la factura. En este caso bastaría tener un print().
Usa verbos antónimos
Usar convenciones facilita la tarea de los programadores tanto de los que escriben como de los que leen ya que las convenciones nos aportan consistencia y simetría y por lo tanto legibilidad. En el caso de los nombres de las rutinas, podemos utilizar verbos que sean antónimos para expresar una acción y la contraria. Algunos ejemplos los tenemos en los siguientes:
add/remove | incremente/decrement | open/close | begin/end|insert/delete | show/hide | create/destroy | lock/unlock | source/target | first/last | min/max | start/stop | get/put o get/set | old/new
Establecer convenciones para acciones comunes
Nos encontramos muchas veces que tenemos operaciones similares a las que llamamos de distinta forma. Un ejemplo de una nomenclatura errónea la tendríamos en nombres de métodos que obtienen el id de un objeto. Imaginemos que tenemos los siguientes: employee.id.Get() o dependent.GetId() o candidate.id() o supervisor.getId() …etc. Todas estas operaciones en el fondo hacen lo mismo pero tienen diferentes nombres. Usar una convención para este tipo de casos nos facilitaría la labor de lectura del código.
3. ¿Cuál es la longitud adecuada para una rutina?
Esta pregunta no tiene una respuesta única de verdad absoluta. La experiencia nos dice que mientras más pequeñas, es decir, con menos líneas de código, más fáciles de comprender. Personalmente, más que la métrica de líneas de código, me gusta poner el foco en que la rutina tenga una única responsabilidad. Teniendo esto en cuenta y llevando el concepto lo más lejos posible si cada rutina hace una única tarea lo normal es que escribamos rutinas más cortas.
4. ¿Cómo usar los parámetros de una rutina?
Básicamente aquí me estoy refiriendo a diferenciar los parámetros de una rutina en dos tipos: operandos y opciones.
Los operandos serían aquellos valores con los que opera la rutina y las opciones representan modos de funcionamiento.
Sobre este asunto ya escribí un artículo hace varias semanas así que lo dejo aquí y os invito a leerlo.
Ya veis que si nos ponemos a pensar detenidamente en todo lo que implica escribir una rutina la tarea tiene más chicha de lo que pudiera parecer en un principio. Espero que os haya gustado y aportado algo de valor.
Chimpún.
