2010-04-02 15 views
8

Estoy desempolvando un viejo proyecto mío que calcula una serie de métricas simples sobre grandes proyectos de software. Una de las métricas es la longitud de los archivos/clases/métodos. Actualmente mi código "adivina" dónde los límites de clase/método se basan en un algoritmo muy tosco (recorren el archivo, mantienen una "profundidad actual" y lo ajustan siempre que encuentres corchetes sin comillas; cuando vuelves al nivel una clase o método comenzó en , considere que salió). Sin embargo, hay muchos problemas con este procedimiento, y una forma "simple" de detectar cuándo ha cambiado su profundidad no siempre es efectivo.¿Fuente de analizadores para lenguajes de programación?

Para que esto dé resultados precisos, necesito usar la forma canónica (en cada idioma) de detectar definiciones de funciones, definiciones de clases y cambios de profundidad. Esto equivale a escribir un analizador simple para generar árboles de análisis sintáctico que contengan al menos estos elementos para cada idioma al que quiero que se aplique mi proyecto.

Obviamente, los analizadores se han escrito para todos estos idiomas anteriormente, por lo que parece que no debería duplicar ese esfuerzo (aunque escribir analizadores es divertido). ¿Existe algún proyecto de código abierto que recopile bibliotecas de analizador listas para usar para varios lenguajes de origen? ¿O debería simplemente usar ANTLR para crear el mío desde el principio? (Nota: estaría encantado de transferir el proyecto a otro idioma para hacer uso de un gran recurso existente, así que si conoce uno, no importa en qué idioma esté escrito)

+1

Hay librerías de resaltado de sintaxis (los pygments vienen a la mente) que manejan muchos lenguajes diferentes. Me pregunto si alguno de ellos proporcionaría suficiente información para su caso. Sospecho que no, pero valdría la pena echarle un vistazo. – Ken

Respuesta

6

Si desea un análisis preciso del idioma, especialmente frente a las complicaciones del lenguaje, como las macros y los condicionales del preprocesador, necesita analizadores de lenguaje completo. En realidad, estos son bastante trabajo de construir, y la mayoría de los lenguajes no se prestan muy bien a los diversos tipos de generadores de analizadores. Tampoco la mayoría de los autores de un analizador de lenguaje están interesados ​​en otros lenguajes; tienden a elegir algún generador de analizador sintáctico que obviamente no es un obstáculo enorme cuando comienzan, implementan su analizador para el propósito específico que pretenden y continúan.

Consecuencia: hay muy pocas bibliotecas de definiciones de lenguaje que se definen con un solo formalismo o una base compartida. La multitud ANTLR mantiene uno de los conjuntos más grandes en mi humilde opinión, aunque por lo que puedo decir la mayoría de los analizadores no son capaces de producción. Siempre hay Bison, que ha existido lo suficiente, por lo que esperaría que se recopilara una biblioteca de definiciones de idioma en algún lado, pero nunca he visto una.

Pasé los últimos 15 años definiendo la maquinaria de base para el análisis y la transformación de programas, y construyendo otra biblioteca de este tipo, llamada DMS Software Reengineering Toolkit. Tiene analizadores de calidad de producción para C, C++, C#, Java, COBOL (versión Enterprise de IBM), JCL, PHP, Python, etc. Su opinión puede variar de la mía pero se usan a diario con DMS para llevar a cabo tareas de cambio masivo en grandes cuerpos de código.

No conozco ningún otro en el que el conjunto de definiciones de idioma estén maduras y estén construidas sobre una única base ... puede ser que los compiladores de IBM sean un conjunto así, pero IBM no ofrece la maquinaria o las definiciones del lenguaje

Si todo lo que quiere hacer es calcular métricas simples, es posible que pueda vivir solo con lexers y recuento de nidos ad hoc (como ha descrito). Incluso eso es más difícil de lo que parece para hacerlo funcionar en la mayoría de los casos (consulte las sintaxis de cadenas locas de Python, Perl y PHP). Cuando todo está dicho y hecho, incluso C es una sorprendente cantidad de trabajo solo para definir un lexer preciso: tenemos varias miles de líneas de expresiones regulares sofisticadas para cubrir todos los lexemas extraños que se encuentran en Microsoft y/o GNU C.

Dado que DMS tiene analizadores maduros consistentemente definidos para muchos idiomas, se deduce que DMS tiene lexers maduros consistentemente definidos para los mismos idiomas. De hecho, construimos un Source Code Search Engine (SCSE) que proporciona una búsqueda rápida en grandes cantidades de códigos en varios idiomas que funciona al leer los idiomas que encuentra e indexar esos lexemas para una búsqueda más rápida. El SCSE simplemente calcula el tipo de métricas que está discutiendo, ya que indexa la base del código, más o menos de la forma en que describe, excepto que tiene estos lexers precisos para usar.

+0

Ira, gracias por una respuesta fascinante! El kit de herramientas de reingeniería de software de DMS se parece más a una versión más grande (más bien pensada, menos centrada en las métricas) de lo que trato de hacer. Hmm. Es interesante que menciones PHP, porque eso es exactamente lo que me llevó a la decisión de que necesitaba un analizador real. Si puedo preguntar, ¿tiene alguna recomendación si decido escribir mis propios analizadores para varios idiomas? (De nuevo, mirando el sitio web de Diseños Semánticos, las estrategias para escribir una serie de analizadores de este tipo pueden raya en los secretos comerciales. Si eso es así, ignore la pregunta). – Arkaaito

+1

No hacemos nada que sea secreto. La estrategia para escribir analizadores fácilmente es obtener la tecnología de análisis más sólida que pueda obtener (GLR), la definición de lenguaje más precisa (PHP no funciona bien esta prueba), codificar una gramática y meter millones de líneas de código en busca de fallas. El verdadero problema es solo sudar; incluso con esta estrategia, se necesita mucha energía para cada idioma. El objetivo de construir DMS era evitar duplicar la infraestructura común para cada idioma nuevo (ya hacía 25 años que hacía este tipo de cosas antes de decidir crear DMS). –

2

estar interesado en gcc-xml si está analizando C++. Java CUP tiene gramáticas para el lenguaje Java.

+0

gcc-xml no dará ninguna información sobre los cuerpos de funciones, solo declaraciones. Es difícil obtener métricas útiles cuando solo se ven encabezados de función. –

Cuestiones relacionadas