GeneXus - Estilo de codificación y refactorización del código fuente

En el artículo anterior les comenté un poco sobre "análisis estático de código".

Me quedaron un par de temas pendientes a tratar (si bien los mencioné en la sección de recursos):

• Programming style (Estilo de programación o codificación) http://en.wikipedia.org/wiki/Programming_style
• Code refactoring (Refactorización de código) http://en.wikipedia.org/wiki/Code_refactoring

¿Cuál es la correlación con análisis estático de código?

Las "guías o reglas de estilo" ayudan a detectar cuales son las infracciones (desviaciones a los estándares definidos).
Y la refactorización del código, permite la corrección automática de esas infracciones.

De esta forma sería posible que una herramienta corrija código aplicando los patrones de estilos, buscando además patrones de código con "malas prácticas" y  transformando los mismos en una codificación válida y unificada.

Para que realmente exista utilidad, debería de permitir aplicar diferentes estándares (propios o usar de terceros) y permitir incorporar conocimiento sobre los patrones a identificar (malas prácticas). Todo el proceso de corrección debería de ser efectuado de forma automática o asistida.

Ejemplos prácticos en GeneXus

Marcos Crispino nos comentó (en enero) sobre temas relacionados a Refactoring http://blog.marcoscrispino.com/2009/01/refactoring-de-cdigo-genexus.html

Algo que menciona Marcos, es referente al trabajo realizado por Matias Barrios, sobre el proyecto GxVisualindent (http://www.gxopen.com/gxopen/servlet/projectinformation?755), el cual se encarga de la indentación de código fuente en GeneXus 9.

Luego Matías basándose seguramente en las ideas de Marcos instauró el proyecto RefactorinGX (http://www.gxopen.com/gxopen/servlet/projectinformation?757), el cual implementa métodos que permiten identificar algunos casos, aplicando correcciones o informándolas.

Sin embargo no encontré en la comunidad ejemplos que mezclen los conceptos de "declaración o definición de estilo de codificación" y detección de patrones (que se encuentren declarados) para luego ser detectados y refactorizados.

Espero que a futuro aparezcan herramientas que permitan implementar análisis estático de código y refactorización de programas GeneXus.

Por el momento, solamente puedo adelantarles que estoy trabajando en un proyecto relacionado a estos temas (Pero que no necesariamente se atacarán estos temas a corto plazo).
Seguramente pronto tendrán novedades sobre el mismo en éste mismo medio.

---

Recursos

Para el caso de "Las guías o estándares", no conozco mucho que se encuentre de acceso público en internet.
Los que pude localizar son los mencionadas a continuación (si conocen alguna más, se agradece el aporte para irlo incorporando al listado)

Nomenclatura GIK : http://wiki.gxtechnical.com/commwiki/servlet/hwiki?GIK,

GIK & GxSoft Nomenclaturas :
http://gxsoft.googlepages.com/gik%26gxsoftnomenclaturas
http://www.scribd.com/doc/289187/Nomenclatura-GxSoft-vs-GIK

Ejemplo usado en el proyecto ModsGX (Facultad de Ingeniería)http://www.fing.edu.uy/inco/cursos/ingsoft/pis/memoria/experiencia2002/ModsGX/modelo/introduc/metgen.htm#_Toc16527191

Seguramente en las empresas existen documentos del tipo "manual de nomenclaturas" o "manual de estándares de programación" o algún documento del tipo "buenas prácticas de programación", en donde traten los temas relacionados a estándares de codificación.
Principalmente lo que busca cada uno de estos estándares es unificar, permitiendo que cualquier programador que conozca el estándar, pueda leer y entender los programas sin mayores problemas (mejor comprensión para revisión y mantenimiento).

Para finalizar les dejo algunos ejemplos aplicados para otros lenguajes de programación:
http://en.wikipedia.org/wiki/Programming_style#Coding_conventions_for_languages

Para refactorización tienen la sección de "Automated code refactoring" mencionado en la Wikipedia
http://en.wikipedia.org/wiki/Code_refactoring#Automated_code_refactoring

GeneXus - Análisis estático de código

A todos los programadores!!!

No importa la buena educación en programación tengas, ni que tan experimentado seas, o todo el esfuerzo y buena voluntad que pongas en tu trabajo, está comprobado que en algún momento se termina colando  algún error o bug en el sistema.

El incremento en la complejidad de los sistemas, hace que sea imposible programar libre de errores, somos humanos, por lo tanto existe la posibilidad de que por descuido o error, un defecto termine en la casa del cliente.

Es por ese motivo que cada día se necesita de la ayuda de herramientas que realicen un análisis totalmente automático del código fuente, (a efectos de no permitir fugas de errores ya conocidos).

¿Análisis del código fuente?

El concepto de "análisis de código" es muy amplio, seguramente si le preguntamos a un conjunto de programadores llegaremos a una lista muy larga de posibles definiciones. Al ser un tema tan diverso y confuso, es necesario que se aclare el mismo desde un principio.

Análisis estático de código

Formalmente se denomina "Análisis estático de código" (Static Code Analysis en inglés).
Estático se refiere a que se analiza el software (código) sin que el mismo se encuentre en ejecución.

Existen varios tipos de análisis, algunos de los cuales pueden ser divididos en diferentes categorías dependiendo del valor que cada uno de estos provea.
Intentaré mencionar solamente las categorías más comúnmente utilizadas:

• Revisión de Código
  Este tipo de herramientas generalmente realizan análisis automatizado mediante la carga y "parseo" del código, en búsqueda de patrones de programación particulares que violen un conjunto de reglas establecidas.
  
  
• Dependencia de código
  Examina la relación entre el código fuente y sus dependencias para crear un mapa de toda la arquitectura de la aplicación.
  
  
• Complejidad de código
  Analizan y comparan la complejidad del código de los programas (métricas) para determinar que parte del sistema es innecesariamente complejo.
  
  
• Tendencias
  Las herramientas de análisis de tendencias, no usan los artefactos de código de forma directa, de lo que se encargan es del estudio de las mejoras o degradaciones en la calidad del código, basándose en los resultados de los análisis de las otras categorías anteriormente mencionados.
  Se intentaría responder la siguiente pregunta: ¿Estamos logrando un mejor código o estamos empeorando la situación?
  

Beneficios del análisis estático de código.

Algunos beneficios ya fueron mencionados "entre líneas", sin embargo, es mucho más básico como dos razones simples: ahorrar tiempo para ahorrar dinero.

Uno de los aspectos del ahorro de tiempo es muy obvio, se toma mucho menos tiempo en obtener código de mejor calidad frente a la realización de la inspección por método manual.
El detectar los errores de forma temprana permiten a su vez ahorrar tiempo y dinero, pero no solo eso, ahorrarse inconvenientes en etapas en donde dar vuelta atrás y perder tiempo para corregir un problema ya no sería aceptable (y menos cuando el problema sucede en casa del cliente).

Para finalizar, quiero dejar claro que este tipo de herramientas son simplemente una herramienta complementaria que nos ayudan en mejorar la calidad del sistema, por lo tanto no debe de tomarse como sustituto de la revisión realizada de forma manual (y del uso de otras técnicas y herramientas relacionadas a la calidad de nuestro producto).

---

Recursos

A continuación algunos recursos para aquellos que quieran conocer más del tema (o algunas de sus ramificaciones)

En la Wikipedia:

Static Code Analysis http://en.wikipedia.org/wiki/Static_code_analysis
La categoría http://en.wikipedia.org/wiki/Category:Static_code_analysis

Software Metrics http://en.wikipedia.org/wiki/Software_metric
La categoría http://en.wikipedia.org/wiki/Category:Software_metrics

Automated Code Review http://en.wikipedia.org/wiki/Automated_code_review

Programming Style http://en.wikipedia.org/wiki/Programming_style

Code Refactoring http://en.wikipedia.org/wiki/Code_refactoring

En la comunidad GeneXus:

Métricas y complejidad
GXPoints Counter http://www2.gxtechnical.com/portal/hgxpp001.aspx?15,8,8,O,S,0,,1761s

Descuidos, dependencias y limpieza (cosas en desuso):
KBDoctor http://wiki.gxtechnical.com/commwiki/servlet/hwiki?KBDoctor

Visualización de dependencias:
The GXArchitect http://www2.gxtechnical.com/portal/hgxpp001.aspx?15,27,347,O,S,0,APP;E;1010;0;APP;APA;1010;0;4;APA;MNU;E;90;4;MNU;,

Si conocen alguna herramienta GX relacionada con estos temas y no la tengo en la lista, avisen.

GeneXus - Liberación de GXLicInfo v0.2

En anterior oportunidad mencioné sobre un proyecto llamado GXLicInfo.

Si bien aún no fue liberado su código fuente, logré cerrar algunos temas de estética y compatibilidad (Incorporando por ejemplo el soporte de GXtest de Abstracta).

Hoy fue liberada para uso público y gratuito la versión 0.2 de GXLicInfo.
La misma se encuentra libre y sin restricciones de uso para toda la Comunidad GeneXus.

Quien piense que le puede ser de utilidad y quiera unirse al "Betatesting" ¡¡¡puede hacerlo!!!

Se encuentra de forma pública en GX Plataform Gallery bajo la sección External Tools: http://gallery.genexus.com/

Lamento no brindar una buena documentación, sin embargo les dejo el dato de que si tienen instalado GeneXus X o X Evo 1, es solo cuestión de correr desde línea de comando el programa GXLicInfo.exe o desde el explorador de Windows el archivo RunForest.cmd (para listar la misma información en una ventana de comando emergente).

Para aquellos que tienen versiones anteriores a la X y quieren utilizarlo, existe una alternativa para hacerlo (la cual funciona pero no recomiendo). Para ese caso, recomiendo leer el documento notas.txt proporcionado con el archivo de instalación.

Espero sea de utilidad