2010-05-19 12 views
7

Me acaban de dar una nueva tarea que parece va a ser un desafío interesante.Análisis del código estático para un nuevo idioma. ¿Donde empezar?

El cliente desea que se desarrolle una herramienta de comprobación de estilo de código para su lenguaje de programación interno (que pronto será de código abierto) que se ejecuta en la JVM. La sintaxis del lenguaje es muy similar a Java.

El cliente básicamente quiere que produzca algo como checkstyle.

Así que mi pregunta es: ¿cómo abordarías este problema? Dado un borrón y cuenta nueva, ¿qué recomendaciones le harías al cliente?

creo que tengo 3 opciones

  1. Escribe algo desde cero. Id prefiero no hacer esto, ya que parece que este tipo de problema con la herramienta de análisis de código se ha resuelto tantas veces que debe haber un enfoque más orientado hacia el "marco" o la "plataforma".

  2. Tenedor una herramienta de comprobación de estilo de código existente y modificar el análisis sintáctico para adaptarse a este nuevo lenguaje, etc, etc

  3. Extender o el enchufe en una herramienta de análisis de código estático existente. (Tal vez escribir un plugin para Yasca?)

Respuesta

4

Tales herramientas, básicamente, tiene que implementar un front-end del compilador para al menos un subconjunto del lenguaje. El punto de partida más fácil es a menudo adaptar un front-end de compilador existente, por lo que definitivamente debe comenzar por mirar el compilador de su cliente. Si tiene suerte, tendrá una separación limpia entre el front-end y el back-end y podrá usarlo tal como está y usar el AST o cualquier IR que el front-end produzca para hacer su análisis adicional.

+0

Sí, o use un generador de analizador si esto no es posible. –

0

Tome un vistazo a FindBugs

+0

Sí, FindBugs, PMD checkstyle etc etc Los documentos indican que es extensible, pero parece que toda la magia se realiza en el nivel de código de bytes. Así que, de manera automática, esto podría detectar problemas en el código de bytes generado, pero luego podría ser bastante difícil mapear estos errores en el código fuente de este nuevo idioma. – tinny

1

No desea escribir todo esto desde cero.

Ver el DMS Software Reengineeering Toolkit. Esto ha generalizado la maquinaria del compilador para analizar, construir AST, construir tablas de símbolos, construir/atravesar flujo de control y gráficos de flujo de datos y árboles de llamadas.

DMS puede obtenerse con una interfaz completa de Java que construye AST, tablas de símbolos y los análisis de flujo anteriores. DMS maneja dialectos de idiomas con aplomo, por lo que debe ser tan sencillo como práctico modificar esta interfaz para que coincida con el lenguaje de variantes de Java de su cliente y, sin embargo, adquirir toda esta maquinaria de análisis.

0

¿Qué hay de PMD? He usado PMD durante años, pero nunca he profundizado en su funcionamiento interno antes.

PMD puede ampliarse escribiendo un analizador de lenguaje personalizado, que se realiza proporcionando implementaciones de lo siguiente dentro de un JAR en la ruta de clase.

net.sourceforge.pmd.cpd.Language
net.sourceforge.pmd.cpd.Tokenizer

http://pmd.sourceforge.net/cpd-parser-howto.html

Entonces utilizando el PMD rule designer I puede definir reglas de la AST resultante.

Lo que me gusta de PMD es que es una herramienta de análisis de código ampliamente reconocida en el espacio de Java, por lo que tiene mucho soporte de terceros. Por ejemplo, el plugin Eclipse, el complemento Hudson CI, etc.

Cuestiones relacionadas