[ Viene del hilo Damas Inglesas O Checkers ]

jsbsan escribió: [Ver mensaje]

Os traigo mi ultimo programa, que es un juego de damas inglesas.

Esta basado en el programa que hizo  por Ken Goldberg  en SmallBasic, donde usa el algoritmo minimax para elegir la mejor jugada (tiene varios niveles de dificultad). En mi version, tambien se pueden crear posiciones para jugar, ademas de guardar y abrir partidas.

Espero que os guste...

Saludos

Felicitaciones Julio. A mi me ha gustado mucho.

Citar:

Pues si, aunque parte del trabajo estaba hecho (gracias al código Ken Goldberg Enlace), el adaptarlo a gambas me ha costado, sobre todo porque SmallBasic maneja listas, y eso en gambas lo he tenido que hacer con clases y arrays de clases.

Ufff, portar un programa de un lenguaje a otro no es un trabajo trivial, para nada. Especialmente cuando, como dices, un lenguaje dispone de características que el otro no y principalmente cuando, como en este caso, SmallBasic es un lenguaje procedimental y gambas tiene un muy buen soporte para programación orientada a objetos.

Creo que deberías refactorizar el código que portaste para mejorar aún más su modularidad, especialmente si continuarás trabajando sobre el programa, corrigiendo errores y añadiendo características. Si le das un vistazo rápido al libro Refactoring: Improving the Design of Existing Code, de Martin Fowler verás cómo puedes mejorar mucho el código para que sea más fácil modificarlo.

O también podrías empezar por intentar aplicar los conceptos básicos de objetos como guía para mejorar el código, que por ser portardo desde un lenguaje procedimental obviamente carece del tipo de modularización típica de un programa orientado a objetos.

Existe una diferencia notoria entre el código de las clases que creaste que es mucho más limpio y conciso que el código del formulario Main y del módulo cálculos. Parece evidente que el código de las clases refleja un diseño que te viste obligado a realizar por las diferencias en los lenguajes, mientras que el código que era más fácil de traducir es muchísimo menos modular porque refleja el diseño del programa original.

Algunos tips:

• Cuando encuentras dos bucles anidados, el bucle interno tiene que ir a otro método.
  
• No deberías tener clases o módulos con cientos de líneas, a menos que se trate de bibliotecas.
  
• Cuando tienes un método con más de 15 líneas es probable que ese método esté haciendo varias cosas, en vez de especializarse en hacer sólo una tarea. En esos casos si revisas el nombre del método verás que no refleja lo que realmente realiza.
  

El ejercicio constante de refactorización te ayudará a entender en profundidad cómo escribir programas con menos errores, más fáciles de modificar y de ampliar. En definitiva, te hará un mejor programador, más productivo y eficiente.

Saludos.

===================
Cómo programar con Gambas

Speed Books: informática libre.

Fabianv:

Citar:

Creo que deberías refactorizar el código que portaste para mejorar aún más su modularidad, especialmente si continuarás trabajando sobre el programa, corrigiendo errores y añadiendo características.

Si, la verdad es que el código esta algo confuso... .  

Citar:

Existe una diferencia notoria entre el código de las clases que creaste que es mucho más limpio y conciso que el código del formulario Main y del módulo cálculos. Parece evidente que el código de las clases refleja un diseño que te viste obligado a realizar por las diferencias en los lenguajes, mientras que el código que era más fácil de traducir es muchísimo menos modular porque refleja el diseño del programa original.

Si es correcto tu comentario, al principio me base en la estructura del programa original, pero debido a las diferencias, empecé a crear clases. Ademas cuando he añadido mejoras, las fui añadiendo en el formulario Fmain

Citar:

El ejercicio constante de refactorización te ayudará a entender en profundidad cómo escribir programas con menos errores, más fáciles de modificar y de ampliar.

Si, creo que merece la pena mejorar el codigo de este programa, sobre todo porque se puede usar en crear mucho más tipos de juegos (desde as distintas variantes de las Damas, hasta otro tipo de juegos de tablero basado en turnos).

Citar:

Refactoring: Improving the Design of Existing Code

¿Sabes si hay una traduccion en castellano?
He mirado en internet, y aparece en un post de un blog, un resumen del libro ( Enlace ), y la verdad que parece muy interesante.

Saludos

===================
Blog personal
Web: SoloGambas seleccion de articulos dedicados a Gambas
Visita el Curso de Gambas3 ¡¡¡Gratuito!!!

jsbsan escribió: [Ver mensaje]

Citar:

Refactoring: Improving the Design of Existing Code

¿Sabes si hay una traduccion en castellano?
He mirado en internet, y aparece en un post de un blog, un resumen del libro ( Enlace ), y la verdad que parece muy interesante.
Saludos

Encontré este apunte de la Facultad de Informática de la Universidad de Buenos Aires que te puede resultar útil para orientarte. De todos modos, tienes que ir con cuidado y paso a paso porque gambas no provee un framework de pruebas que es una condición necesaria para poder refactorizar de forma racional.

Saludos.

PD: no olvides revisar la consola de advertencias de gambas, que aunque tiene una funcionalidad limitada alguna ayuda te brindará.

===================
Cómo programar con Gambas

Speed Books: informática libre.

Hablamos de refactoring o lo que se asemeja re-estructurar.

Si es una re-estructuración del código, es una mejora del mismo.
¿ Y como mejoras el código ?, como estamos partiendo de otro lenguaje, se debería
entender mejor el lenguaje del que parte para poder convertir al nuestro. O buscar
un lenguaje que se asemeje mas al nuestro y así convertir mejor.

Si solo nos basamos en el nuestro, lo que no de la experiencia no va a crear cambios.
Si un programador se limita solo a crear una aplicación en este caso funcional, muchos
nos contentamos con su funcionamiento por diferentes motivos.

Si yo hago una aplicación que muestra números primos. Puedo empezar a comenzar a hacerla
con código masificado. Luego aprendo funciones y reparto el código en módulos.Dependiendo de
lo que quiera conseguir.

Con el paso del tiempo he aprendido dos maneras de hacerla.Existirá una tercera usando clases.
Y aun así, el código podrá seguir teniendo cambios. Cambios que te han llevado a mejorar,
optimizando mejor el código, a comprender a usar mejor tu lenguaje.

Si me planto delante del ordenador y hago la aplicación.Y me quedo revisando una vez acabada,
¿ como puedo mejorarla ?. A parte de frustración que acabas mordiéndote la lengua por no saber mas.

Cuando hago una aplicación. me paro hasta el lugar que no entiendo.Acabo haciendo otros pequeños
ejemplos para entender mejor como funciona cada miembro de mi aplicación.

A veces el problema principal  es no saber como funciona una pequeña instrucción.
O peor, del código de otro lenguaje que has partido no  es tan correcto  como debería ser y
confiabas ciegamente en el. Error.  La documentación explicaba como hacer el código,
pero luego algo faltaba.El código del ejemplo era de una manera y luego el código que expone ya hecho, es otro!.

Otras,los autores que deberían saber enseñar y no complicar al que intenta aprender, desde el primer capitulo.
Aprender desde el principio y mal. Es como darte un alicate y usarlo para clavar clavos.

Os cito aquí una frase que me hace mucha gracia al comenzar un libro de programación.

"Lo que nos queda es seguir aprendiendo a programar en XXXX.Lo demás es estudiar y practicar  sin dejar de disfrutar".
Toma castaña.Si no explica del principio como se debe usar un archivo para no repetirlo tropecientas veces!.

Y una vez que tengas experiencia, podremos hacer "refactoring".  
Experiencia, perdida de pelo...y que no vuelve.

Saludos.

===================
Gambas Básico
"No es un bug, es una característica no documentada"

Shell escribió: [Ver mensaje]

Si es una re-estructuración del código, es una mejora del mismo. ¿Y como mejoras el código ?, como estamos partiendo de otro lenguaje, se debería entender mejor el lenguaje del que parte para poder convertir al nuestro. O buscar un lenguaje que se asemeje mas al nuestro y así convertir mejor.

Sí, exacto. Muchos lenguajes imperativos son muy similares y aprender a leer código de esos lenguajes es algo relativamente sencilllo, por ejemplo, es algo bastante sencillo leer código Java, C#, VB.Net, si sabes gambas. Todo programador debería desarrollar la habilidad de leer código de otros lenguajes de similares características, aunque ello no significa saber programar en ellos.

Shell escribió: [Ver mensaje]

Si solo nos basamos en el nuestro, lo que no de la experiencia no va a crear cambios.

No sé si entiendo bien lo que intentas decir, pero para refactorizar tienes que aprender a refactorizar, que no es lo mismo que saber escribir un programa bien modularizado desde el comienzo.

Shell escribió: [Ver mensaje]

Si yo hago una aplicación que muestra números primos. Puedo empezar a comenzar a hacerla con código masificado. Luego aprendo funciones y reparto el código en módulos.Dependiendo de lo que quiera conseguir.

Con el paso del tiempo he aprendido dos maneras de hacerla.Existirá una tercera usando clases. Y aun así, el código podrá seguir teniendo cambios. Cambios que te han llevado a mejorar, optimizando mejor el código, a comprender a usar mejor tu lenguaje.

Aprender a programar antes de lanzarse a programar es una condición obvia, nadie corre antes de aprender a caminar ¿cierto?

Shell escribió: [Ver mensaje]

Si me planto delante del ordenador y hago la aplicación.Y me quedo revisando una vez acabada, ¿ como puedo mejorarla ?. A parte de frustración que acabas mordiéndote la lengua por no saber mas.

No entiendo lo que quieres decir. En 1er lugar, un programa que calcula números primos no puede considerarse una aplicación. Estas poniendo el ejemplo de alguien que recién comienza sus 1eros pasos en la programación. En 2do lugar, si esa persona no sabe programar o sabe muy poco, no es aconsejable que intente realizar una aplicación completa por sí sólo, porque obviamente la experiencia será muy frustrante. Y por último, si esa persona tomó la decisión de lanzarse a programar una aplicación con sus casi nulos conocimientos de programación, no puede preguntarse ¿cómo puedo mejorarla? porque ni siquiera sabe programar realmente.

Shell escribió: [Ver mensaje]

Cuando hago una aplicación. me paro hasta el lugar que no entiendo. Acabo haciendo otros pequeños ejemplos para entender mejor como funciona cada miembro de mi aplicación.

Si ahora estás hablando de tí mismo, partiendo de la base de que ya posees los conocimientos mínimos necesarios como para escribir ciertos tipos de aplicaciones, creo que ese procedimiento que realizas es perfecto y no todos los programadores tienen conciencia de que deberían proceder de esa manera.

A ese tipo de ejemplos si son pequeñas aplicaciones se les denomina breakable toys, como una analogía con un niño pequeño que necesita poder manipular juguetes que pueda romper si es necesario, para aprender.

Si se trata de ejemplos de uso de características del lenguaje, en realidad sería bueno estructurarlos como casos de uso y transformarlos en pruebas unitarias.

Hay un libro interesante que describe ciertos patrones de aprendizaje en programación que se llama Apprenticeship Patterns (en inglés).

Shell escribió: [Ver mensaje]

A veces el problema principal  es no saber como funciona una pequeña instrucción.
O peor, del código de otro lenguaje que has partido no  es tan correcto  como debería ser y confiabas ciegamente en el. Error.  La documentación explicaba como hacer el código,
pero luego algo faltaba.El código del ejemplo era de una manera y luego el código que expone ya hecho, es otro!.

Otras,los autores que deberían saber enseñar y no complicar al que intenta aprender, desde el primer capitulo.

La existencia de código que no funciona en un libro para aprendices es un defecto importante. Pero eso no es lo mismo que el enfoque pedagógico (o anti-pedagógico) que tenga el libro. Lo menciono porque esto es un problema recurrente en los libros sobre programación.

Shell escribió: [Ver mensaje]

Aprender desde el principio y mal. Es como darte un alicate y usarlo para clavar clavos.

Os cito aquí una frase que me hace mucha gracia al comenzar un libro de programación.

"Lo que nos queda es seguir aprendiendo a programar en XXXX. Lo demás es estudiar y practicar  sin dejar de disfrutar".
Toma castaña.Si no explica del principio como se debe usar un archivo para no repetirlo tropecientas veces!.

En pedagogía hay un principio básico que se le atribuye a Confucio que declara que hay que ir de lo fácil a lo difícil. El problema es que los lectores de un libro no tienen todos los mismos conomientos previos y, en consecuencia, lo que es fácil para unos puede no serlo para otros.

A esto hay que sumarle el hecho de que un libro presenta un camino de aprendizaje estático. A veces puede que el autor sea ingenioso o sepa sobre pedagogía y didáctica y plantee en su libro diversos caminos de aprendizaje, lo cuál es muy bueno, pero no dejan de ser caminos estáticos. Es decir, el libro nunca se va a poder adecuar al proceso de aprendizaje que se vaya produciendo en el lector. Por ello, el lector tiene que asumir un rol activo y convertirse en su propio maestro, tiene que tomar decisiones sobre qué caminos de aprendizaje seguir, incluso a pequeña escala, incluso mientras lee un libro de programación y practica los ejercicios propuestos.

También se atribuye a Confucio la frase: "Me lo contaron y lo olvidé; lo vi y lo entendí; lo hice y lo aprendí."

El problema con muchos libros es que sus autores no tienen conocimientos de pedagogía y su intuición, sus teorías implícitas sobre cómo las personas aprenden, muchas veces los conducen a tomar decisiones erróneas.

Los libros que probablemente nunca deberías leer son aquellos que presentan una estructura secuencial que parece ir de lo fácil a lo difícil, pero que no presentan cantidades suficientes y sobre todo adecuadas de ejemplos y ejercicios, o aquellos que presentan muchos ejercicios pero todos iguales o muy parecidos. Por supuesto, puede haber excepciones.

Otra cuestion diferente es que un libro proponga un abordaje que no es apropiado para tí. Por ejemplo, un posible abordaje sería plantear situaciones problemáticas desde el comienzo y explicar los conceptos involucrados mientras se proponen soluciones a esa situación. Sin embargo, muchas personas rechazan un enfoque pedagógico que es adecuado, porque es diferente a lo que están acostumbrados. Por ejemplo, si el enfoque del libro plantea en primer lugar contra-ejemplos o le requiere al lector que piense una posible solución a un problema antes de mostrarle "cómo se debería solucionar ese problema", muchas personas dirían que ese libro es muy malo, cuando en realidad lo que ocurre es que adoptan una postura dogmática por la que pretenden que el autor debería haberles mostrado cuál era "la forma correcta de hacerlo".

El planteamiento temprano de situaciones problemáticas y de contra-ejemplos es un recurso didáctico que se usa para ayudar a disparar procesos reflexivos en el aprendiz. Si el aprendiz tiene una postura pasiva, el enfoque fracasará, no porque sea malo, sino porque el aprendiz no comprende que debe abandonar su actitud pasiva (dime cómo se hace, no me hagas pensar demás).

Shell escribió: [Ver mensaje]

Y una vez que tengas experiencia, podremos hacer "refactoring".    Experiencia, perdida de pelo...y que no vuelve.
Saludos.

Profesionalmente, la refactorización se aplica a dos situaciones:

1) Tienes que mantener un programa que no escribiste tú, probablemente un programa escrito hace varios años y que está mal estructurado.

2) Estás escribiendo un programa (como parte de un equipo), tienes que cumplir con fechas de entrega, tienes que lidiar con el hecho de que en el equipo los programadores no tienen los mismos conocimientos y experiencia, estás trabajando bajo cierta presión,  y existen otros factores que indefectiblemente llevarán a que aunque el equipo pueda entregar software funcional en cada fecha límite, ese código no tenga la calidad requerida para que se pueda continuar el desarrollo sin que se presenten a futuro problemas que provoquen parálisis en el desarrollo.

Por ello se introduce la noción de que la práctica constante de la refactorización debe ser un paso fundamental en cada iteración para ir corrigiendo los pequeños defectos que acumulados harán que el código se vuelva inflexible, y así evitar posibles efectos de bola de nieve.

Aprender a programar no es sólo aprender un lenguaje. Es comprender que el software tiene un ciclo de vida, que desarrollar software exige seguir un proceso de desarrollo (que en el 99% de los casos debería ser iterativo), que no se puede esperar a que el programa esté terminado para comenzar a probarlo (hay que escribir pruebas unitarias y de integración desde el principio) y también otras cosas que nada tienen que ver con el lenguaje de programación que se use.

Volviendo al tema del refactoring, si estás aprendiendo a programar, la refactorización no es lo primero que debes aprender; lo primero es aprender programación orientada a objetos porque (entre otras cosas) es el marco conceptual que te ayudará a comprender cómo debes modularizar tus programas.

Si aprendes POO (mensajes, objetos, encapsulamiento/ocultamiento de información, agregación/composición, herencia/ducktyping/polimorfismo, traits, pruebas unitarias/xUnit, etc), entonces el aprendizaje posterior de la refactorización será cuestión de aprender a aplicar adecuadamente un conjunto de procedimientos, pero los conceptos que le dan fundamento (qué se quiere lograr al hacer tal cosa y por qué) ya los conocerás bien.

Eso no quiere decir que no se pueda seguir otro camino. Alguien que ya tiene algunas nociones sobre POO y se pone a estudiar refactorización, se verá obligado a profundizar y a completar tus conocimientos sobre POO, aunque es probable que ese camino de aprendizaje sea más complicado, pero depende mucho de cada persona.

Saludos.

===================
Cómo programar con Gambas

Speed Books: informática libre.

interesante pero siempre que se discute de programación
se habla de codigo y lenguajes
sin embargo lo importante ocurre antes de escribir el codigo
antes de abrir el ide y antes de saber  un  lenguaje
 
podrás ser el mejor constructor del mundo conocer todas las técnicas
y saber usar todas las herramientas y maquinarias
pero sin los planos jamas lograras construir un edifico

codificador escribió: [Ver mensaje]

interesante pero siempre que se discute de programación
se habla de codigo y lenguajes
sin embargo lo importante ocurre antes de escribir el codigo
antes de abrir el ide y antes de saber  un  lenguaje

La programación no es sinónimo de codificación o implementación. Es también diseño, análisis, metodología, proceso de desarrollo, gestión de equipos, etc. Es decir que engloba todas las actividades que sean necesarias para programar una computadora para que realice una cierta tarea (de un cierto nivel de abstracción).

La visión que estás expresando es la visión del taylorismo de la división del trabajo en los procesos de producción. Y es todo lo contrario a lo que se propone a partir de los procesos iterativos e incrementales de desarrollo y en particular se opone a la visión que proponen las metodologías ágiles.

Las grandes empresas de consultoría, las "picadoras de carne", siempre se construyen con base en esta visión taylorista de la división del trabajo y de la estrategia de que los "recursos humanos" (los desarrolladores) deben ser fácilmente reemplazables, como lo era cualquier máquina o parte en una cadena de montaje, en la época de expansión de la revolución industrial.

El taylorismo no es que sea algo malo en sí mismo, sino que no es algo que se pueda aplicar universalmente y definitivamente no debería aplicarse al desarrollo de software.

Básicamente lo que muchas empresas del sector pretenden es que realmente sea posible tener unos pocos arquitectos que son quienes realizan el trabajo de mayor valor y mano de obra de menor calificación para que realice la implementación.

La idea de estas empresas es que a los arquitectos, por supuesto, se les paga mejores sueldos y esto les convene porque se trata de una cantidad menor de puestos de trabajo y la implementación implica mano de obra intensiva que requiere menos calificación y que es realizada por "codificadores" que reciben salarios mucho más bajos.

Este es el ideal del gerente de tecnología de modelo taylorista, pero realmente no tiene nada que ver con lo que la programación es en realidad.

codificador escribió: [Ver mensaje]

 podrás ser el mejor constructor del mundo conocer todas las técnicas
y saber usar todas las herramientas y maquinarias
pero sin los planos jamas lograras construir un edifico

Eso es todo lo contrario a las nociones más elementales de desarrollo de software actuales.

Jamás podrás tener el plano detallado y completo de un programa antes de ensuciarte las manos, porque para que ello sea posible, es necesario que puedas controlar absolutamente todas las variables en juego (todas las cosas que pueden cambiar) y ello sólo es posible en tipos de proyectos muy particulares basados en principios matemáticos, físicos, etc, es decir, que tienen una casuística que puede determinarse a partir de leyes universales previamente conocidas, por lo que todos los efectos probables se pueden predecir.

Además, ese tipo de proyecto, que se presta perfectamente para un desarrollo en cascada, tiene costos económicos altísimos y suele incluir el desarrollo del software para un hardware específico que también se desarrolla como parte del proyecto.

El 99% de los proyectos de desarrollo de software no caen en esa categoría, sino que requieren de un proceso de desarrollo iterativo e incremental en el que se desarrollan todas las actividades que implica la programación, en tanto sean necesarias, durante todo el tiempo de desarrollo del proyecto (con diferentes esfuerzos o énfasis según se necesite). El diseño emerge de este proceso iterativo e incremental, por lo que es imposible que alguien dibuje un plano como paso previo a la "construcción".

===================
Cómo programar con Gambas

Speed Books: informática libre.

fabianfv escribió: [Ver mensaje]

La visión que estás expresando es la visión del taylorismo de la división del trabajo en los procesos de producción. Y es todo lo contrario a lo que se propone a partir de los procesos iterativos e incrementales de desarrollo y en particular se opone a la visión que proponen las metodologías ágiles....

no no quise decir todo eso

si no algo totalmente diferente

aveces la interpretación mas simple de un comentario en un foro es la correcta

codificador escribió: [Ver mensaje]

no no quise decir todo eso

No, por supuesto que no quisiste decir todo eso.

codificador escribió: [Ver mensaje]

si no algo totalmente diferente

Bueno, pero es que nadie puede juzgar lo que quisiste decir, sino sólo lo que dijiste.

codificador escribió: [Ver mensaje]

aveces la interpretación mas simple de un comentario en un foro es la correcta

La cuestión no es que yo haya malinterpretado lo que decías, sino que expresaste una visión de la programación que es equivocada y que, aunque no te des cuenta, está basada en la aplicación de metáforas extraídas de la producción industrial (de hace 100 años), de la construcción y, en general, de la ingeniería tradicional, que desde hace muchos años se han intentado aplicar forzadamente al desarrollo de software.

En cierta medida, no podemos escapar de esas metáforas, porque están muy arraigadas: hablamos de "construcción" (build, building), "arquitectura", "planos", "arquitectos de software", etc. Por ejemplo, la mala aplicación de ciertas metáforas provoca que coloquialmente hablemos de idiomas o lenguas para referirnos a los sistemas de comunicación oral y escrita que usamos los seres humanos y al referirnos a la programación decimos "lenguaje" que si bien es un sinónimo, no es la palabra con la que generalmente expresamos esa idea. Por lo tanto, a cualquier estudiante de programación hay que explicarle qué es un lenguaje de programación cuando, en principio, debería ser una noción obvia.

Habitualmente hablamos en términos de aprender a hablar, escribir, leer y pensar en otro idioma como el inglés, pero nunca decimos que debemos aprender a leer, a escribir y a pensar en C++, en Java o en gambas. Por suerte Bruce Eckel tituló una serie de sus libros como "Piensa en...(Java, C++, etc)" y a partir de allí se extendió una mínima noción sobre que un lenguaje de programación es un idioma, una lengua de comunicación con las computadoras.

Decimos que un programa se compone de "sentencias", en vez de decir "oraciones" o "frases". Otra vez, "sentencia" es un sinónimo de "oración", pero no es la palabra que usamos habitualmente para designar esa idea y, además, en este caso se trata de una mala traducción (traducción literal) de la palabra inglesa "sentence".

Hay infinidad de ejemplos de aplicaciones incorrectas de metáforas al desarrollo de software, pero algunas, como las metáforas referidas a los procesos industriales o a la construcción, son particularmente perjudiciales y son utilizadas para menospreciar nuestra actividad y a los trabajadores de nuestro sector.

Bueno, ya se ha desviado el tema del hilo, tal vez algunos mensajes deberían ser movidos a uno nuevo.

===================
Cómo programar con Gambas

Speed Books: informática libre.

Fabian:

Es una pena que no te dediques a escribir. Maestro.
Ya no lo digo por un libro de gambas, si no un libro de programación en general sin entrar
en ningún lenguaje concreto.

Por falta de tiempo no puedo extenderme mucho en el ultimo mensaje.Y me gustaría responderte mejor,
intentando no desviarme demasiado. Y es que no tenia nada que ver con el juego de las damas.

Ayer estuve viendo diferentes IDE, entre ellos Geany y como veo que es tan sencillo para comenzar con Java,
no es que sea el más adecuado, pero mejor comprender lo principal y luego comenzar con otros IDE como
NetBean o Eclipse para comodidad. Si se quiere entender las raíces, mejor de 0.

En Linux los programadores pioneros usaban siempre el editor de texto para programar.
Que luego dicen, que no hay tantos IDE en Linux por esta costumbre...

Fue con Codelite dedicado a C/C++ encontré curiosamente un menú que hacia referencia a la
palabra refactoring.

Dentro de su menú C++ encontré:

-Code Generation / Refactoring
---Insert DoxyGen Comment
---Generate Setters/Getters
---------------------------------
---Move Function Implementation to..
---Add Function Implementation
---Implemment All Un-implemment Functions
---------------------------------
---Implemment inherits virtual functions
---Implemment inherits pure virtual functions
---------------------------------
---Rename Symbols.

Como C++ es un derivado de C la "transformación" es de lo mas corriente que exista un menú.

Saludos.

===================
Gambas Básico
"No es un bug, es una característica no documentada"