Por fortuna ya son muchos los que utilizan nomenclaturas y estilos de programación bien definidos. Aún así, durante mi trayectoria profesional, he tenido el dudoso privilegio de toparme con muchos más que no lo hacen.
He de decir que esto no ocurre sólo en ambientes que pudiéramos llamar de
bajo perfil tecnológico, sino en empresas de consultoría de primer nivel. Desde mi punto de vista, debido a la contratación indiscriminada de la época .com.
Este es uno de los factores imprescindibles para conseguir código de calidad, primer paso de una cadena en la que aparece el
refactoring de
Kent Beck y
Martin Fowler, y su importancia es mayor cuanto mayor es el proyecto y el equipo.
Durante los incontables años que llevo programando, mi estilo y nomenclatura han ido variando, adaptándose a los entornos y lenguajes, y mejorando con la experiencia adquirida, y tengo claro que seguirán cambiando como algo vivo.
Hoy hablaré sólo de nomenclatura, próximamente seguiremos con el estilo (mucho más interesante), y me centraré en los entornos más extendidos hoy en día: Java y .NET.
Nombres de clase
En este ámbito caen tanto las clases como los interfaces.
Durante bastante tiempo utilicé prefijos para nombrar clases e interfaces, anteponiendo una C o una I, respectivamente. En .NET se utiliza de hecho esta convención para con los interfaces, mientras que en Java no se hace distinción. Personalmente creo que la I no aporta nada y por eso he dejado de utilizarla. No aporta nada porque los interfaces son nuestra cara al exterior (buena práctica:
codificar hacia interfaces), y al usuario de nuestros interfaces poco le importa si aquello que usa es un interfaz o una clase, su uso no varía, por tanto la I creo que añade datos innecesarios y con ello empeora el estilo. No obstante, en .NET puede ser recomendable utilizarla para mantener la coherencia con el entorno.
En general, los nombres de clase o interfaz deben constar de una o más palabras representativas, completamente escritas salvo que sean abreviaturas ampliamente extendidas, capitalizadas en su primera letra y sin guiones bajos u otros artefactos entre ellas. Ejemplo:
DataObject.
Como extensión, creo que es buena práctica añadir al nombre de clase el patrón de software que representa en caso de representar alguno. Ejemplo:
DataObjectFactory.
Nombres de métodos y propiedades públicas
Mi consejo en este sentido es utilizar las normas expuestas en las diferentes guías de estilo de los entornos.
Por ejemplo, en Java el nombre está compuesto de la misma forma que hemos explicado para los nombres de clase, pero con la primera palabra completamente en minúsculas. Ejemplo:
provideSomeInfo().
En .NET la nomenclatura es idéntica a la del nombre de clase, siguiendo el ejemplo:
ProvideSomeInfo().
Nombres de variables y propiedades privadas o protegidas
La nomenclatura propuesta en Java o .NET es similar, e igual a la propuesta para los métodos y propiedades públicos.
Durante mucho tiempo he empleado mi propia variación de la notación húngara propuesta por Charles Simonyi, fruto de mi herencia de C/C++, pero ciertamente en los lenguajes más puramente orientados a objetos como Java o C# tiene menos sentido y es un tema sobre el que se podría
debatir
Algunas normas básicas
Es imprescindible que los nombres sean siempre representativos, y expliquen bien el cometido de un método o variable, no os importe tener que escribir más porque el incremento en la calidad y legibilidad del código os pagará cuando tengáis que revisarlo.
Únicamente puede saltarse la excepción de utilizar nombres genéricos, de una letra, en el caso de contadores enteros usados en bucles, restringiendo estos a los tradicionales en matemáticas: i, j, k, m, n. Y además en este orden suponiendo bucles anidados. Esto último es importante para mantener la coherencia y prevenir errores en zonas muy anidadas (que no deberían ocurrir, pero eso pertenece al estilo).
