language-agnostic editing

language agnostic - ¿Mejorando la forma en que escribimos código?



language-agnostic editing (30)

La última mejora que he visto es el resaltado de sintaxis y la ayuda sensible al contexto

Entonces no has mirado mucho. Los IDE modernos pueden hacer mucho, MUCHO más que eso, es decir, mostrarle la estructura semántica del código (por ejemplo, jerarquías de herencia) e incluso manipularlo (refactorización automática) o enriquecerlo con datos externos (como quién fue el último en cambiar una línea de código en particular) .

Mientras pensaba en la ingeniería de software en general, me di cuenta de por qué no vemos ninguna mejora en la forma en que escribimos / documentamos el código.

Piénselo: no ha habido una mejora revolucionaria desde que pasamos de las tarjetas perforadas a la edición de texto. La última mejora que he visto es el resaltado de sintaxis y la ayuda sensible al contexto (por ejemplo, Intellisense o ctags). No es algo que llamaría revolucionario.

Eso me hace preguntarme: ¿Por qué es así?

Empezaré con algo que echo mucho de menos:

  • Mucho de mi código trata con la geometría. Para la documentación que describe las relaciones geométricas, siempre termina en un montón de cosas matemáticas difíciles de leer (debido a la falta de configuración de tipo de ecuación adecuada en ASCII). Sin embargo, si pudiera insertar un pequeño dibujo o garabatear en el código, todo sería mucho más fácil, más ordenado y mejor para ser comprendido.

¿En qué puede pensar que haría más fáciles sus tareas de codificación / edición de texto / documentación?

No ha habido una mejora revolucionaria desde que cambiamos de tarjetas perforadas a edición de texto

Nunca usé un editor de líneas, ¿verdad?

Pero en serio, el texto (especialmente en las representaciones elegidas para los idiomas modernos) es

  1. fácilmente procesado
  2. bastante fácil de especificar
  3. información densa
  4. preciso

Todo lo que venga a reemplazarlo debe ser una ganancia neta en las cuatro de esas propiedades. No es fácil.

¿Ha utilizado Doxygen o similar para documentar su código? Puede agregar enlaces a imágenes y otros tipos de archivos (a menudo almacenados en el mismo directorio que el código fuente) que se verán afectados por la documentación generada. Me doy cuenta de que este es un paso para ver los detalles directamente en su editor favorito, pero definitivamente mejora la forma en que documentamos nuestro código.

Ciertamente respeto el argumento de Fred Brooks No Silver Bullet , pero creo que la forma en que escribimos el código no es ni mucho menos óptima, por lo que hay mucho más espacio para mejorar. Traté de explicar esto en mi libro .

Todos estamos familiarizados con el "código de golf", donde compites incansablemente para minimizar algo. Esa es una buena manera de acercarse al valor mínimo posible de ese algo.

Lo bueno de esto es que se le permite, incluso se lo alienta, romper con las tradiciones, las concepciones anteriores, la sabiduría aceptada, en la búsqueda de ganar. En resumen, aprendes cosas nuevas.

Si la medida a minimizar es el tiempo de ejecución del reloj de pared, puede realizar una optimización agresiva.

Si la medida es el tamaño del código fuente (líneas o caracteres), se obtiene "código de golf".

La medida que más me gusta es "editar cuenta". Es decir, dada una base de código, supongamos que aparece un nuevo requisito. Ese requisito se implementa, completamente, editando el código base. Luego se hace un "diff" desde el antiguo al nuevo código base. El número de diferencias encontradas es el recuento de edición. Promediado sobre el conjunto de probables nuevos requisitos funcionales, esa es la medida para minimizar.

Si esto se hace de manera agresiva, siendo libre de contradecir toda la sabiduría convencional, la base del código se aproxima a un estado que llamaría un lenguaje específico del dominio (DSL). En este lenguaje, los conceptos expresados ​​en código están en casi 1-1 correspondencia con conceptos orientados a problemas. En este estado, no es fácil que el código fuente sea auto inconsistente (es decir, tenga errores) porque cuantas menos ediciones se deban realizar en el código fuente, hay menos posibilidades de cometer un error. También es el caso que dicho código tiende a ser corto. Pero a diferencia del "código de golf", tiende a ser muy claro, porque mapea los conceptos del problema con tanta claridad.

Por lo tanto, las herramientas y técnicas que ayudan a minimizar el recuento de ediciones pueden, en mi opinión, considerarse "balas de plata". DSL es uno de ellos. La generación de código es otra. Mi técnica de optimización favorita es otra. Para la codificación de UIs dinámicamente cambiantes hay una ejecución diferencial . Seguro que habrá más, esperando ser descubiertos. Por supuesto, todo depende de la capacitación y experiencia del "tirador" (el codificador).

Creo que hay muchas nuevas ideas por descubrir. El truco es decir la diferencia entre los que nos hacen avanzar, y los que nos frenan.

Creo que aquí es donde Doxygen y otros sistemas de documentación ayudan. Si podemos insertar comentarios pequeños y discretos que enlazan con otra información como:

/* help: fooimg.png */

Y luego hacer que un sistema de documentación externo haga eso, entonces genial.

Aún mejor sería permitir que nuestro editor de texto trate esas cosas como hipervínculos a la documentación externa.

Creo que deberías echarle un vistazo a Leo . Este es un intento de los chicos de responder lo que preguntas. Todavía no puedo envolver mi VIM personalmente, pero otros lo hacen rápidamente. No es solo un IDE de programación, sino más bien un organizador de información. Está escrito en Python, pero no veo por qué no puedes codificar en otros idiomas con él. El poder de Leo no es tanto el lenguaje, sino la capacidad de expresar sus pensamientos y organizarlos ya sea en código, diagramas, imágenes o diagramas. Revise el tutorial y los ejemplos para familiarizarse con él. Quizás te guste.

Creo que los IDE integrados con resaltado semántico y ** sugerencias semánticamente restringidas * (a la IDEA o Eclipse) son un gran avance.

Pero eso sucedió hace 8-10 años.

La programación basada en plantillas parece útil y nunca parece tener éxito. Recientemente me impresionó una demostración del sistema de Meta-programación , que aprovecha la naturaleza interactiva del IDE para simplificar la tarea de escribir plantillas y cuáles son las macros (esencialmente) de tipo.

La meta-programación podría ayudarlo a definir macros basadas en geometría que sustituirían a varias líneas de código. Podría imaginar algo que te permita integrar un ''lenguaje matemático'' más legible dentro de Java y luego analizar su contenido en algo legible por máquina.

Difundir y buscar imágenes es difícil. La diferencia y la búsqueda son muy importantes para los programadores. El uso de imágenes en lugar de texto es solo una mejora marginal en muchas situaciones, tiene algunos inconvenientes y requiere una aceptación general antes de que realmente valga la pena hacerlo (ya que no hace las cosas más comprensibles si su lector no se queja de lo que ha dicho). hecho).

Además, los programadores tienen un millón de pequeños trucos que les hacen la vida más fácil, según las representaciones de texto del código, que perderían si les diera un código para leer que se expresara en cualquier otra cosa que no fuera texto. Claro, pueden reemplazar o volver a implementar esos trucos con el tiempo, pero a corto plazo se han ido.

Tampoco se ve a los abogados cambiando de inglés a pequeños diagramas de servilletas en los contratos (las licencias Creative Commons intentan, pero no pueden hacer que la imagen sea la representación formal del contrato). Probablemente por razones similares.

Si a alguien se le ocurre un lenguaje de programación e IDE que, en general, supera a los basados ​​en texto; y lo comercializa con éxito; luego verá el inicio de un cambio revolucionario del texto a un nuevo formato. Si a nadie se le ocurre algo así, entonces no nos lo estamos perdiendo. Si a alguien se le ocurre algo que es más productivo pero no gana fuerza debido a las ventajas independientes de otras tecnologías, entonces esa pérdida es el precio que pagamos por el capitalismo de libre mercado. Quizás las ideas sean recicladas eventualmente ...

Dicho esto, la integración entre el código y la documentación podría mejorarse claramente, y hay muchos esfuerzos en curso para hacerlo, utilizando varias técnicas con diferentes éxitos. Nuevamente, el problema es que cualquier plan de astucia en particular solo puede implementarse en la práctica en uno o varios idiomas y entornos de desarrollo a la vez, por lo que tiene dificultades para demostrar que realmente es mejor. La incrustación de documentación en el código es posiblemente el único avance universal desde la invención de la API ...

Sin embargo, creo que todavía hay mucho que se puede hacer con el texto. Por ejemplo, la tecnología de depuración hace una gran diferencia en la productividad del programador en ciertas circunstancias comunes (a saber: cuando una prueba falla o si ocurre algo inesperado, pero no es obvio cuál es la suposición errónea en el código que está viendo). En términos de mejorar la programación, puede haber frutos más bajos que el negocio real de expresar el programa.

Dos citas vienen al instante a la mente:

"Si no está roto, no lo arregles". "Usa la mejor herramienta para el trabajo".

Por supuesto, aunque el código central todavía está escrito como texto, todas las herramientas y bibliotecas han cambiado enormemente desde los días de las tarjetas perforadas.

DrScheme te deja hacer estas cosas. Aquí están las cosas que puede insertar desde el sitio web de PLT:

http://docs.plt-scheme.org/drscheme/Menus.html#(part._.Insert)

3.1.6 Insertar

  • Insertar cuadro de comentario: inserta un cuadro que DrScheme ignora; Úsalo para escribir comentarios para las personas que leen tu programa.
  • Insertar imagen ...: abre un cuadro de diálogo de búsqueda de archivos para seleccionar un archivo de imagen en formato GIF, BMP, XBM, XPM, PNG o JPG. La imagen se trata como un valor.
  • Insertar fracción ...: abre un cuadro de diálogo para una fracción de notación mixta e inserta la fracción dada en el editor actual.
  • Insertar letras grandes ...: abre un cuadro de diálogo para una línea de texto e inserta una versión grande del texto (utilizando puntos y comas y espacios).
  • Insertar λ: inserta el símbolo λ (como un carácter Unicode) en el programa. El símbolo λ normalmente está enlazado igual que lambda.
  • Insertar cuadro de comentarios de Java: inserta un cuadro que DrScheme ignora. A diferencia del elemento de menú Insertar cuadro de comentarios, esto está diseñado para los niveles de idioma de ProfessorJ. Ver profesorJ.
  • Insertar cuadro de interacciones de Java: inserta un cuadro que permite expresiones y declaraciones de Java dentro de los programas Scheme. El resultado de la casilla es un valor de Esquema que corresponde a los resultados de las expresiones Java. En este momento, los valores del esquema no pueden entrar en el cuadro. El cuadro aceptará una declaración o expresión Java por línea.
  • Insertar cuadro XML: inserta un XML; Consulte Cajas XML y cajas de esquemas para obtener más información.
  • Insertar cuadro de esquema: inserta un cuadro que contiene el código del esquema, que generalmente se usa dentro de un cuadro XML; Ver cuadros XML y cuadros de esquema.
  • Insertar caja de empalmes de esquema: inserta una caja para contener el código de esquema, que generalmente se usa dentro de un cuadro XML; Ver también Cajas XML y Cajas de Esquema.
  • Insertar Pict Box: crea un cuadro para generar una imagen de presentación de diapositivas. Dentro del cuadro de imagen, inserte y organice los cuadros de Esquema que producen valores de imagen.

También inserta las pruebas unitarias con el código que está probando. Cosas bastante lindas.

Esto ha sido mencionado por otros, y no revolucionaría la programación, pero de todos modos ...

Creo que sería bueno si los editores de código se movieran ligeramente más allá de los editores de texto plano. Incluso con el resaltado de sintaxis y la finalización del código (que creo que son cosas increíblemente buenas), los editores de hoy (al menos, los que uso) siguen mostrando exactamente el mismo texto ASCII (o la codificación que se use) que se encuentra en los archivos de origen. . Me interesaría ver qué tan bien funcionaría si se mostraran los editores, por ejemplo (algunos ejemplos son más aventureros que otros):

  • Comentarios en un cuadro de texto con un fondo azul claro y sin // o /* ... */ visible
  • Los comentarios de Javadoc podrían tener compatibilidad con la edición de texto semi-enriquecido (para aquellos que hacen comentarios de Javadoc en HTML) (seriamente, agradecería que los editores de código representaran los comentarios de Javadoc como HTML porque no son los más fáciles de hojear cuando su HTML es texto simple) )
  • Funciones en los cuadros de texto que se pueden contraer para mostrar solo la firma (los editores actuales pueden hacer el colapso) y se pueden arrastrar como cuadros
  • Líneas entre cuadros de función para indicar cómo se conectan las funciones
  • Reducción del zoom para que, en lugar de ver un solo archivo de origen (clase en muchos idiomas), pueda ver múltiples archivos y la forma en que se conectan entre sí (esto esencialmente sería crear diagramas similares a UML directamente en el editor de código)

Creo que esto (al menos en mi opinión) funcionaría sin requerir un marcado adicional en los archivos de origen, por lo que los usuarios de editores de texto simple no se verían en desventaja al tener todo este marcado adicional que abarrota los archivos.

Estoy en desacuerdo. Tenemos cambios, pequeños, pero cambios.

¿Qué tan común es el constructo "para cada"? Compáralo con hace 20 años. ¿Qué tal el movimiento de Lenguajes Específicos del Dominio? ¿Qué pasa con la idea de que deberíamos codificar en capas? ¿Qué hay del desarrollo impulsado por el comportamiento? Codificación cumpliendo con una especificación ... que escribe un buen documento como salida cuando todo funciona bien. ¿Qué tal la estandarización de las expresiones regulares? PCRE . ¿Qué hay del trabajo relacionado con DSL del grupo de Alan Kay sobre la "Ley de software de Moore", que exploró una implementación más avanzada de El Cairo y generó un código TCP / IP usando diagramas de RFC?

La documentación es un diálogo bidireccional. Tanto como el código es más comprensible y las personas que aprenden este lenguaje especial. No dirías que el alemán necesita documentación si sabes alemán. Sé que los lenguajes naturales están muy lejos de los lenguajes informáticos, pero hay un movimiento para hacer que el código sea más expresivo. No se trata de las nuevas herramientas, se trata de cómo estamos codificando.

Estoy sorprendido de que nadie parece haber mencionado la Programación literaria seminal de Donald Knuth; escriba su código como si fuera un libro o un artículo científico.

Hace unas semanas, el " Software intencional " creó un gran revuelo acerca de su nuevo idioma. Todavía no he visto la presentación , pero aquí hay una cita de una reseña de Martin Fowler :

Comenzaron de forma preocupante, con los Powerpoints poco reveladores habituales, pero luego pasaron a mostrar la mesa de trabajo y la cortina finalmente se abrió. Para medir la reacción, echa un vistazo a Twitter.

  • @pandemonial Muy impresionado! ¡Esto es dulce! Múltiples dominios, múltiples idiomas, no hay preguntas sin respuesta
  • @csells OK, ver un circuito eléctrico en vivo renderizado y trabajar en un archivo C # es muy bueno.
  • @jolson Dos palabras para decir sobre la demostración de electrónica para Intentional Software: HOLY CRAPOLA. Eso es, mi cerebro finalmente ha explotado.
  • @gblock No se trata de demos elegantes, se trata de cambiar por completo el mundo que lo conocemos.
  • @twleung ok, la inteligencia para las fórmulas actuariales es simplemente increíble
  • @lobrien Esto es como ver un carburador de 100 mpg: ¡Dios mío, alguien va a comprar esto y ponerlo en una bóveda!

He estado pensando mucho sobre cómo hacer que la codificación sea más rápida y eficiente en los últimos años, siempre tratando de hacerlo realista y haciendo implementaciones minimalistas. Esas no son ideas revolucionarias, pero como el póster original hablaba sobre la transición de la tarjeta perforada al código, pensé en hablar sobre otras formas de comunicar a la computadora lo que queremos programar.

Mis ideas son la programación visual o vocal. La motivación detrás de esto es que solo hay varias formas en que un ciclo se puede programar de manera eficiente, y un IDE consciente podría tomar algunas decisiones de sustitución de códigos inteligentes dependiendo de las entradas que no sean las líneas de código escritas.

Programación visual frente a codificación : encapsule (literalmente) el código en "cuadros" que tienen entradas y salidas, y conéctelos en una línea de tiempo horizontal. Este es un concepto de alto nivel que sería intrínsecamente interesante para el desarrollo de subprocesos múltiples, ya que puede tener varias líneas o subprocesos sucediendo al mismo tiempo. Cada proceso se puede dividir en una "caja", sin importar cómo lo veas. El envío de un correo electrónico en su forma más básica es un buzón que toma un correo electrónico como entrada y genera una señal de éxito / falla. Dado que las casillas y las líneas se distribuyen en una línea de tiempo, la noción de cronología de eventos y tiempo no se pierde y las líneas de retroalimentación son posibles.

Programación vocal frente a codificación : la efectividad de esta técnica giraría en torno a la efectividad de la sintaxis vocal que se decidió crear código y mover el cursor. Por ejemplo, puede decir al micrófono "para la variable cero a 10" y el sistema generará automáticamente el siguiente código colocando el cursor dentro:

for (x=0;x<10;x++){ // Cursor would be there after after the call }

En términos de facilidad de uso, debería estar en una sala relativamente silenciosa para minimizar otros sonidos que podrían dañar el reconocimiento de voz, por lo que esta tecnología podría utilizarse en entornos especializados en su mayoría.

Este es el resultado de mi amplia experiencia en programación utilizando una amplia gama de hardware y lenguajes de programación. Déjame saber lo que piensan, me encantaría tener una discusión constructiva sobre eso.

He usado emacs, me gustan las macros de texto. Pero, lo que realmente quiero es analizar macros. Me gustaría que mi editor exponga la maquinaria detrás de la refactorización de tal manera que pueda escribir mis transformaciones en el árbol de lenguaje del lenguaje mismo.

Por ejemplo, Python agregó += en un punto cuando mi código estaba lleno de x = x + 1 líneas. Si hubiera podido escribir un comando de búsqueda y reemplazo que funcionara en el árbol de análisis, podría haber limpiado rápidamente grandes cantidades de mi código fuente.

Por lo tanto, quiero una búsqueda y reemplazo estándar, pero la quiero en el nivel donde la estructura de mi código tiene un significado, en el árbol de sintaxis abstracta.

Si alguna vez ha usado ReSharper, cada una de sus refactorizaciones y recomendaciones están escritas de la manera que describo, encuentran un patrón en el árbol de análisis y sugieren un reemplazo, o para una refactorización, aplique un reemplazo conocido. ¡Quiero acceder a esa maquinaria para mis propias tareas!

La capacidad de hacer una sección de código de solo lectura es algo que he querido

Los lenguajes de programación son una forma especializada de notación matemática, ya que puede expresar matemáticamente un lenguaje de programación. La notación cambia lentamente, por lo que no obtenemos un progreso rápido en nuestros idiomas. Principalmente, avanzamos cuando se nos ocurre algo nuevo para encajar en la notación, como usar i para referirnos a la raíz cuadrada de la negativa.

Hay esquemas de documentación que le permiten incrustar cosas que no sean texto. Hubo al menos un esquema de programación, la Web de Donald Knuth, que le permitió tener una presentación y una versión de ejecución de un programa (desafortunadamente, el código fuente base, las cosas que realmente hackearía, era bastante desordenado).

Fácilmente podría tener un editor de texto que podría tratar los comentarios como HTML, dado que, por supuesto, podría reconocer los comentarios como los vio.

Me atrevo a decir que en realidad podría ser un nuevo lenguaje de desarrollo (quizás incluso un nuevo paradigma) para llevarnos a través de tal revolución;

Me referiría a un dibujo como referencia en la documentación del código. No veo ninguna razón por la que no puedas tener notas al pie en el código.

Me sorprende que nadie haya mencionado todavía No Silver Bullet . En 1986 (!), Frederick Brooks predijo que:

No existe un desarrollo único, ya sea en tecnología o en técnica de gestión, que por sí solo prometa una mejora de diez órdenes de magnitud dentro de una década en productividad, confiabilidad, simplicidad. [...] No podemos esperar ver dos veces ganancias cada dos años ".

Y en 23 años, se ha comprobado que tiene razón. Hemos ideado varias cosas, como el resaltado de sintaxis y el Intellisense, que han mejorado significativamente la productividad, pero ciertamente no en un orden de magnitud. A medida que avanza el tiempo, continuaremos realizando varias mejoras incrementales, pero el hecho es que no hay una bala de plata : no habrá una revelación mágica en la forma en que escribimos el código que mejorará la productividad en un orden de magnitud.

Me sorprende que nadie lo haya mencionado: javadoc es básicamente HTML, por lo que no hay nada que le impida incrustar imágenes (o cualquier otra cosa) en el código. Simple, efectivo y ubicuo, es una de las cosas que Java hizo bien.

Parte del problema podría deberse al hecho de que cuando no codifica no lo llamamos programación: ensamblar componentes modulares mediante una GUI, por ejemplo.

Un traductor del cerebro al ordenador. Escribir es el verdadero cuello de botella. Realmente solo necesita derivar los algoritmos que pienso y convertirlos en código de máquina.

Yo diría que muchos de los lenguajes más nuevos son bastante buenos para crear algoritmos rápidamente. Las mejoras no son tan revolucionarias ahora como son evolutivas.

Una cosa que he hecho recientemente en algunas de las secciones más complejas de mi aplicación es incluir el marcado LaTeX para la ecuación particular como un comentario / cadena de documentación. En este momento, solo copio y pego en un editor de ecuaciones en línea , pero sería muy útil ver la fórmula en sí misma (con cosas como letras griegas y subíndices) en lugar de un montón de código ASCII.

Usted podría estar interesado en estos "lenguajes" de programación alternativos.

[Escalera] [1], diseñada para imitar la forma en que funcionan los esquemas de lógica de relé. Horrible IMO, pero fácil de entender para los viejos que hicieron lógica con palos y piedras. [ http://www.amci.com/tutorials/images/ladder-diagram.gif][2]

[SFC, gráfico de funciones secuenciales] [3], diseñado para simplificar la programación paralela. El código se escribe en cuadros y estos cuadros se pueden colocar paralelos entre sí y, por lo tanto, se ejecutarán simultáneamente. Al conectar el final de varias cajas puede sincronizar eventos. Muy común para aplicaciones de automatización.

[Mathematica] [5] !!!, ¡Puede que no sea el mejor lenguaje de programación pero el resaltado de sintaxis (si puedes llamarlo así) es increíble! Por ejemplo, puede ingresar una matriz al ver que la matriz está bien alineada en lugar de un enorme doble [] []. Los gráficos se pueden insertar en el código y el formato de las expresiones matemáticas parece que lo hace cuando se escribe en un papel. No más locuras de parántesis o expresiones Math.PI largas que realmente solo necesitan un carácter. Y lo mejor de todo, ¡los archivos son solo texto sin formato, incluso si están bien representados en el editor!

Los depuradores también es un área donde se han realizado muchas mejoras. Los depuradores con repetición están comenzando a llegar y también los depuradores visuales donde los datos se pueden modificar en tiempo real. Editar y continuar es también una característica con la que no querría vivir.

WTF "los usuarios nuevos solo pueden publicar un máximo de un hipervínculo" , tendrá que buscar en Google las cosas que originalmente agregué a esta publicación> :(

Yo diría que el control de versiones fue un gran salto en la forma en que trabajamos. La capacidad de mantener un registro completo de cada cambio que alguien haya hecho al código base, y de revertir los cambios cuando sea necesario, ha marcado una gran diferencia.

Código fuente en base de datos . En pocas palabras, el código fuente se analiza y se coloca en una base de datos. Entonces necesitaría un IDE integrado para ver y editar el código, pero en este punto, la sintaxis está desacoplada del formato. SU IDE podría mostrarle un programa de una manera completamente diferente a la de otra persona, en sintonía con la tarea en la que está trabajando. Enumeraré algunos ejemplos específicos, pero ese artículo cubre casi todo.

Transformaciones semánticas automatizadas de código fuente , donde un programa puede ser examinado y manipulado de manera confiable mediante el uso de una interfaz / interfaz abstracta que tenga conocimiento de la semántica subyacente.

De modo que el código fuente puede consultarse y tratarse de manera muy parecida a una base de datos SQL.

Permitiéndole hacer un análisis estático del código fuente y refactorizar incluso el código fuente complejo haciendo algo como:

FIND CALLERS OF FUNCTION "foo" WHERE SIGNATURE("int","int","char*") AND RETURN_TYPE("bool"); ... RENAME MACRO "max" TO "maximum" IN FILE "macros.hxx"; RENAME NAMESPACE "prj" TO "project"; RENAME SYMBOL "OLDFOO" IN NAMESPACE "project"; RENAME FUNCTION "log" TO "show_log"; RENAME CLASS "FOO" TO "OLDFOO"; RENAME METHOD "FOO::inc" TO "FOO::increment"; ... CHANGE SIGNATURE IN FUNCTION "foo" WHERE SIGNATURE("int","int") TO SIGNATURE("double","double"); CHANGE SIGNATURE IN METHOD "myClass::handle" WHERE SIGNATURE("char") TO SIGNATURE("unsigned char") MOVE FUNCTION "foo" in FILE "stuff.cc" TO "foo_funcs.cc";