2012-05-22 9 views
6

¿Se requieren menos comprobaciones/análisis de código menos rigurosos para proporcionar comentarios sobre errores de entorno de desarrollo y finalización automática para lenguajes de programación compuestos principalmente por frases y palabras legibles por el ser humano (es decir, Python, VB.NET)? Esto contrasta con los lenguajes estilo C, que dependen más de símbolos y signos de puntuación para la estructura del código.¿La complejidad de la detección de errores IDE y la autocompletación dependen de la sintaxis del lenguaje?

+1

Antes de definir "más fácil", que evitó, defina "detallado" y "concisa". – jason

+2

@Close Voters: Esta pregunta no se trata de si VB es mejor que C#. – GSerg

+0

Supongo que no se trata de verbosidad; más bien, se trata del hecho de que se permiten más cosas en C# y, por lo tanto, el analizador tiene más formas de interpretar una línea de código. – GSerg

Respuesta

5

Tengo experiencia/soy responsable de la construcción dozens of language front ends.

Los lenguajes de palabras y los idiomas de puntuación son, en general, igualmente difíciles de analizar y analizar estáticamente. La gente que define idiomas de cualquier tipo los ha decorado por décadas (por ejemplo, COBOL desde 1958) o construyendo lenguajes sofisticados (C++, Scala, Ruby) con sintaxis compleja y resolución compleja de nombres y reglas de inferencia tipo ; los proveedores de compiladores luego agregan una sintaxis oscura para admitir las cosas extrañas que hacen o para proporcionar un bloqueo de cliente (por ejemplo, MS "C++ administrado", declaraciones de DLL, etc.). Existe el tercer problema de definiciones pésimas; los idiomas principales pueden tener reglas precisas sobre cómo funcionan, pero muchos idiomas tienen definiciones descuidadas (por ejemplo, PHP) que crea casos oscuros en las esquinas que tienen que resolverse mediante una dolorosa experimentación con la implementación real.

C++ ha sido nuestro peor, esp. con el comité C++ 11 haciendo un lío masivo reciente de cosas. Tenemos analizadores de C++ completos, pero todavía estamos trabajando en la resolución de nombre completo para C++ 11 además de nuestra implementación de C++ 98. (¡El código de resolución de nombre es de unas 250,000 líneas de código y no es suficiente!).

IBM COBOL está en segundo lugar; el lenguaje es simplemente gigante, y hay todo tipo de reglas divertidas de resolución de nombres ("un nombre no calificado puede referirse a un nombre particular sin calificación si la referencia no es ambigua". Entonces, ¿este nombre es una referencia inequívoca en este contexto?).

Una vez que pasa el análisis y la resolución de nombre/tipo, entra en control de flujo, flujo de datos, análisis de puntos, análisis de rango, construcción de gráfico de llamadas, ... que generalmente tienen la misma cantidad de esfuerzo que las fases anteriores; nos salimos con la nuestra teniendo bibliotecas realmente buenas que respaldan estas tareas.

Con todo esto como análisis de fondo, puede comenzar a hacer "análisis estático" del tipo inteligente que la gente quiere.

Otro cartel señaló que la recuperación de errores de sintaxis y (énfasis) "continúan generando mensajes de error significativos". Todo lo que puedo decir es "Amén, hermano". Vea esto SO answer https://stackoverflow.com/a/6657974/120163 para una discusión de qué va mal cuando tiene "programas parciales", que es esencialmente lo que obtiene cuando las reparaciones de errores de sintaxis adivinan una solución.

+0

Esta es la respuesta que estaba buscando. Todo lo que puedo decir es gracias por lo que haces, esto suena realmente desalentador. –

+0

Un buen cumplido, gracias. Hay días en que lamento esta elección particular de carrera: -} –

Cuestiones relacionadas