coding style - style - Cómo escribir un linter?
linter javascript (7)
En mi trabajo diario, yo y otros en mi equipo escribimos muchos modelos de hardware en Verilog-AMS, un lenguaje soportado principalmente por vendedores comerciales y algunos proyectos de simuladores de código abierto. Una cosa que haría que apoyar el código de cada uno sea más útil sería un LINTER que verificaría nuestro código en busca de problemas comunes y ayudaría a imponer un estilo de formato de código compartido. Por supuesto, quiero poder agregar mis propias reglas y, después de probar su utilidad para mí, promocionarlas al resto del equipo. No me importa hacer el trabajo que tiene que hacerse, pero por supuesto también querer aprovechar el trabajo de otros proyectos existentes.
¿Tener la sintaxis de idioma permitida en un formato yacc o bison me da una ventaja? o debería simplemente chupar cada declaración de lenguaje en una cadena perl, y usar la coincidencia de patrones para encontrar las cosas que no me gustan?
(La mayoría de los errores de sintaxis y compilación son fácilmente detectados por las herramientas comerciales ... pero tenemos algunas de nuestras propias extensiones).
Al tratar de encontrar mi respuesta, encontré esto en ANTLR - podría ser útil
Si utiliza Java en absoluto (y por lo tanto IDEA), las extensiones del IDE para idiomas personalizados pueden ser de utilidad.
yacc / bison definitivamente te da una ventaja, ya que una buena pelusa requeriría analizar el programa. Regex (regex verdadero, al menos) podría cubrir casos triviales, pero es fácil escribir código que las expresiones regulares no coinciden, pero que siguen siendo de estilo incorrecto.
lex / flex y yacc / bison proporcionan generadores lexer y analizador fáciles de usar y bien entendidos, y realmente recomendaría hacer algo así en lugar de hacerlo procesalmente en, por ejemplo, Perl. Las expresiones regulares son elementos poderosos para desgarrar cadenas con una estructura relativamente fija, pero no totalmente fija. Con cualquier lenguaje de programación real, el tamaño de su máquina de estado llega a ser simplemente inmanejable con algo menos que un Lexer / Analizador real (tm). Imagine tratar con todos los entrelazamientos posibles de palabras clave, identificadores, operadores, paréntesis superfluos, puntos y comas extraños, y comentarios que están permitidos en algo como Verilog AMS, con expresiones regulares y código de procedimiento solo.
No se puede negar que hay una curva de aprendizaje sustancial allí, pero escribir una gramática que pueda usar para flex y bison, y hacer algo útil en el árbol de sintaxis que sale del bisonte, será un uso mucho mejor de su tiempo que escribir un Una gran cantidad de código de procesamiento de cadenas de casos especiales que se trata de manera más natural con el uso de un árbol de sintaxis en primer lugar. Además, lo que aprendas al escribirlo de esta manera realmente ampliará tus habilidades de manera que escribir un montón de código halagüeño de Perl simplemente no lo hará, así que si tienes los medios, lo recomiendo encarecidamente ;-)
Además, si eres perezoso, echa un vistazo a los complementos de Eclipse que resaltan la sintaxis y la refactorización básica para Verilog y VHDL. Están en un estado increíblemente primitivo, la última vez que lo verifiqué, pero pueden tener parte del código que estás buscando o, al menos, una pieza de código de referencia que debes analizar para mejorar tu enfoque y mejorar el tuyo.
ANTLR parece ser una ruta alternativa al enfoque más común (bueno, ya escuché sobre ellos) YACC / BISON, que resulta ser también comúnmente usado LEX / FLEX como interfaz.
Una lectura rápida de la página de manual de FLEX me hace pensar que podría ser el marco para ese tipo de idea regex.
De acuerdo ... dejaré este guiso un poco más, y luego veré cuán rápido puedo construir un analizador sintáctico prototipo en uno u otro.
y un poco más
He escrito un par de analizadores verilog y sugiero PCCTS / ANTLR si tu lenguaje de programación favorito es C / C ++ / Java. Existe una gramática PCCTS / ANTLR Verilog con la que puede comenzar. Mi generador de analizadores favorito es Zebu, que se basa en Common Lisp.
Por supuesto, el gran trabajo es especificar todas las reglas de deshilado. Tiene sentido hacer algún tipo de lenguaje para especificar las reglas de deshilado también.
No subestime la cantidad de trabajo que entra en un linter. El análisis es la parte fácil porque tiene herramientas (bison, flex, ANTLR / PCCTS) para automatizar gran parte de ella.
Pero una vez que tienes un análisis, ¿qué? Debes construir un árbol semántico para el diseño. Dependiendo de cuán complicadas sean sus entradas, debe elaborar el diseño de Verilog-AMS (es decir, resolver parámetros, desenrollar genera, etc. si usa esas características). Y solo entonces puedes tratar de implementar reglas.
Consideraría seriamente otras posibles soluciones antes de escribir un linter, a menos que el número de usuarios y el posible ahorro de tiempo justifiquen el tiempo de desarrollo.