Por: Fernando D. Bozzo
Cuando se desarrollan nuevas funcionalidades, si queremos hacer las cosas bien lo haremos de forma encapsulada, usando control de errores, evitando en lo posible dependencias externas y parametrizando lo más posible, para intentar que haya claramente una entrada y una salida.
En este proceso, lo primero que elegimos y creamos es el nombre del procedimiento o función que contendrá el código con la implementación de la funcionalidad.
Lamentablemente a este paso muchas veces no se le da la importancia necesaria, siendo que de la claridad con la se defina esto, dependerá buena parte de la autodocumentación de la aplicación, y de que dentro de un tiempo nosotros u otros desarrolladores entendamos qué hacía o por qué.
En este artículo se verán algunos nombres que por su longitud a quienes estén acostumbrados a la vieja usanza les podrá resultar exagerado o demasiado verborrágico, pero es que los tiempos han cambiado y con los años se han aprendido nuevas lecciones por el camino.
Lo que importa es el nombre
Nombres como "procedimiento_1" o "proc_A" no indican absolutamente nada sobre su funcionamiento o intención, incluso algo más elaborado como "EvaluarHabilitaciones" puede ser ambiguo si no se usa correctamente.
Las buenas prácticas indican hacer métodos que hagan en lo posible una sola cosa y usar un nombre que sea lo más representativo posible de esa funcionalidad.
¿Pero qué regla se puede usar para evitar equivocaciones o nombres poco útiles y conseguir el mejor nombre?
Hay una regla muy fácil: Convertir el nombre del método que hemos elegido en una pregunta, y si las respuestas (los valores de salida) no son ambiguas y unívocamente responden a la pregunta, entonces ese es un buen nombre.
Veamos algunos ejemplos
1) Tenemos un método que debe devolver el estado de habilitación (enabled) de un grupo de controles de acuerdo a ciertas condiciones.
Rápidamente podríamos pensar algo como "EvaluarEstadosDeDeshabilitacion", ya que aparentemente este nombre está hablando sobre lo que hace internamente, lo cuál es cierto, y que se usará en una condición de este tipo:
IF EvaluarEstadosDeDeshabilitacion()
* Asignar ENABLED=.T. a unos controles
ELSE
* Asignar ENABLED=.F. a unos controles
ENDIF
Pero sometámoslo a la prueba de la pregunta a ver si es un nombre adecuado, y comparemos las respuestas:
Pregunta:
"¿Se van a
Evaluar Estados de Deshabilitación?"
Respuestas posibles del método:
Verdadero
Falso
En este caso las respuestas confunden, porque ¿se van a evaluar o no esos estados?
Para complicarlo más, el nombre incluye una negación, "Deshabilitación", por lo que al responder afirmativamene, realmente estamos diciendo lo que no se debe hacer en vez de lo que sí se debe hacer. Como se ve, algo que debería ser sumamente sencillo comienza a complicarse sin sentido.
Pero dado que las respuestas del método realmente deben ser esas (Verdadero/Falso), debemos asumir entonces que las pregunta está mal hecha, y por consiguiente el nombre del método está mal.
Volvamos a pensarlo: La respuestas indican si se deben habilitar o no controles, ¿no sería mejor un nombre como "ControlesEvaluadosHabilitados" o "ControlesEvaluadosEnabled"?
Sometámoslo a la misma prueba:
Pregunta:
"¿Están los
Controles Evaluados Habilitados?"
Respuestas posibles del método:
Verdadero
Falso
En este caso ambas respuestas definen precisamente los valores posibles a la pregunta, con lo que ese nombre es el adecuado. Luego, el ejemplo anterior quedaría así:
IF ControlesEvaluadosHabilitados()
* Asignar ENABLED=.T. a unos controles
ELSE
* Asignar ENABLED=.F. a unos controles
ENDIF
2) Tenemos un método que no debe devolver ninguna respuesta, sino solamente evaluar y actualizar los estados de habilitación antes comentados.
En este caso se trata de un método que invoca a otros métodos para realizar su tarea, por lo que aquí sí que "EvaluarEstadosDeHabilitacion" o "EavaluarYActualizarEstadosDeHabilitacion" sería un nombre correcto, ya que se usaría así:
PROCEDURE EvaluarYActualizarEstadosDeHabilitacion
* Hacer las evaluaciones necesarias y configurar los ENABLED
ENDPROC
Pero sometámoslo a la prueba de la pregunta a ver si es un nombre adecuado, y comparemos las respuestas:
Pregunta:
"¿Se van a
Evaluar Y Actualizar Estados de Habilitacion?"
Respuestas posibles del método:
Como no devuelve respuesta, se debe comparar con la veracidad de la intención, que en este caso es SI, se van a Evaluar Y Actualizar Estados de Habilitación.
3) Un nombre de método tomado de un sistema: "Formularios()". No devuelve nada, solo realiza una acción: Cierra los formularios abiertos.
¿Qué nos dice este nombre? Pues que tiene que ver con formularios, pero nada más.
¿Indica su función? No
¿Podemos deducir lo que hace? No
Entonces es un nombre inútil. Para la acción que realiza, un mejor nombre podía ser CerrarFormularios(), y no requería mucha imaginación ni trabajo extra.
4) Algunos ejemplos de nombres usados en casos de prueba automatizados con FoxUnit:
Deberia_Ejecutar_FOXBIN2PRG_ParaLaLibreria_FB2P_TEST_VCX_YValidarLosCamposDelRegistro
Deberia_Ejecutar_FOXBIN2PRG_ParaElForm__F_OptionGroup__YValidarLaVisualizacionDePantalla
Deberia_DevolverLaFechaHora_2013_12_01_08_02_00_ParaElValor_1132544064
Deberia_ObtenerLaUbicacionDelBloque_IF_ENDIF_CuandoCodigoCon_IF_ENDIF_predominante_esEvaluado
Creo que no necesitan ver el código ni los comentarios de estos métodos para saber lo que hacen, y eso es suficiente para demostrar el sentido de estos nombres extra-largos y cuán útiles son.
Resumen
Estas sugerencias de nomenclatura se basan en la forma de pensar natural sobre las cosas: cuando queremos un manzana de la frutería, vamos a ver si "HayManzanasEnLaFruteria", jamás iremos a ver si "
NoHayManzanasEnLaFrutería", ya que la negación no es la forma natural de razonar, y por eso es que no es recomendable usar negaciones en los nombres de los métodos.
Respecto de los nombres largos, hay que hacerlos lo más descriptivos posibles, a tal punto que no requiera tener que inspeccionar el código para saber lo que hacen.
Finalmente, recuerden hacerse la pregunta con el nombre del método: Si las respuestas admitidas son ambiguas o no son del todo exactas, entonces el nombre no está bien elegido y conviene cambiarlo.
Todo esto ayudará enormemente a la autodocumentación de las aplicaciones y a que tanto ustedes como cualquier otro desarrollador puedan saber qué hacen los procedimientos o funciones solo leyendo sus nombres, lo que también facilitará el mantenimiento de la misma, aunque pase mucho tiempo.
Incluso si alguien nuevo debe familiarizarse con el código, estas buenas prácticas lo ayudarán a no perderse y ser productivo en menos tiempo.
Hasta la próxima!
