¿Por qué la mayoría de los lenguajes de programación no anidan los comentarios de bloque?

Algunos lo hacen, pero no ninguno de los populares, que yo sepa. ¿Hay algo malo en anidar comentarios?

Planeo que los comentarios de bloque aniden en el idioma (pequeño) en el que estoy trabajando, pero me gustaría saber si es una mala idea.

Una cosa que nadie ha mencionado todavía, así que lo mencionaré: el deseo de anidar comentarios a menudo indica que el programador está haciendo mal.

Primero, aceptemos que el único momento en que el programador puede "anidar" o "no anidar" es cuando el programador escribe algo estructuralmente como esto:

do_something();
/* comment /* nested comment */ more comment */
do_something_else();

Ahora, ¿cuándo surge tal cosa en la práctica? ¡Ciertamente, el programador no va a escribir comentarios anidados que literalmente se vean como el fragmento anterior! No, en la práctica cuando anidamos comentarios (o deseamos poder anidarlos), es porque queremos escribir algo como esto:

do_something();  /* do a thing */
/* [ajo] 2017-12-03 this turned out to be unnecessary
do_something_else(); /* do another thing */
*/

Y esto es MALO. ¡Este no es un patrón que (como diseñadores de idiomas) queremos fomentar! La forma correcta de escribir el fragmento anterior es:

do_something();  /* do a thing */

Ese código "incorrecto", ese inicio falso o lo que sea, no pertenece a la base de código. Pertenece, en el mejor de los casos, al historial de control de fuente. Idealmente, para empezar, nunca escribirías el código incorrecto, ¿verdad? Y si el código incorrecto cumplía un propósito allí, al advertir a los encargados del mantenimiento que no lo restablecieran por alguna razón, bueno, probablemente sea un trabajo para un comentario de código bien escrito e intencional. Intentar expresar "no hagas X" simplemente dejando algún código antiguo que haga X, pero comentado, no es la forma más fácil de leer o efectiva para evitar que las personas hagan X.

Todo esto se reduce a una simple regla general que quizás hayas escuchado antes: no comentes el código. (Buscando esta frase a su vez, una gran cantidad de opiniones en el acuerdo .)

Antes de preguntar: sí, lenguajes como C, C #, C ++ y ya dan el programador otra herramienta para "comente" grandes bloques de código: #if 0. Pero esta es solo una aplicación particular del preprocesador C, que es una herramienta grande y útil por derecho propio. En realidad, sería extremadamente difícil y especial para un lenguaje admitir la compilación condicional #ify, sin embargo, no admitirlo #if 0.

Por lo tanto, hemos establecido que los comentarios anidados son relevantes solo cuando el programador comenta el código; y hemos establecido (a través del consenso de muchos programadores experimentados) que comentar el código es algo malo.

Para completar el silogismo, debemos aceptar que los diseñadores de idiomas tienen interés en promover las cosas buenas y desalentar las cosas malas (suponiendo que todo lo demás sea igual).

En el caso de los comentarios anidados, todo lo demás es igual: puede ignorar con seguridad las respuestas con bajo voto que afirman que el análisis anidado /*sería de alguna manera "difícil" para el analizador. (Los anidados /*no son más difíciles que los anidados (, que casi todos los analizadores del mundo ya deben manejar).

Entonces, si todo lo demás es igual, ¿debería un diseñador de lenguaje hacer que sea fácil anidar comentarios (es decir, comentar el código) o difícil? Recordemos que comentar el código es algo malo.

QED

Nota. Tenga en cuenta que si no permite comentarios anidados, entonces

hello /* foo*/bar.txt */ world

es un "comentario" engañoso, es equivalente a

hello bar.txt */ world

(que probablemente sea un error de sintaxis). Pero si haces permiten comentarios anidados, a continuación,

hello /* foo/*.txt */ world

es un "comentario" engañoso, es equivalente a

hello

pero deja el comentario abierto hasta el final del archivo (que de nuevo es casi seguro un error de sintaxis). Por lo tanto, ninguna de las dos formas es particularmente menos propensa a errores de sintaxis no intencionales. La única diferencia está en cómo manejan el antipatrón intencional del código comentado.

Debido a que la mayoría de las implementaciones están usando etapas separadas de lexing y parsing, y para la lexing están usando expresiones regulares simples y antiguas. Los comentarios se tratan como espacios en blanco, es decir, tokens ignorados y, por lo tanto, deben resolverse por completo en un pase lexing. La única ventaja de este enfoque es la velocidad de análisis. Numerosas desventajas incluyen limitaciones severas en la sintaxis (por ejemplo, la necesidad de mantener un conjunto fijo de palabras clave independientes del contexto).

Es perfectamente posible hacer un lexer que pueda manejar comentarios anidados. Cuando está comiendo espacios en blanco, cuando ve /*que puede aumentar un contador de profundidad y disminuirlo cuando ve */, y detenerse cuando la profundidad es cero. Dicho esto, he hecho muchos analizadores y nunca encontré una buena razón para anidar los comentarios.

Si los comentarios pueden anidarse, entonces un inconveniente es que es fácil desequilibrar sus extremos y, a menos que tenga un editor sofisticado, puede ocultar invisiblemente el código que supone que está allí.

Una ventaja de los comentarios que no anidan es algo como esto:

/*
some code
more code
blah blah blah
/**/

donde puede comentar fácilmente el código dentro o fuera quitando o agregando la primera línea, una edición de 1 línea. Por supuesto, si ese código contiene un comentario, esto se rompería, a menos que también permita //comentarios de estilo C ++ allí. Entonces eso es lo que tiendo a hacer.

Como nadie más lo mencionó, enumeraré algunos idiomas que admiten comentarios anidados: Rexx, Modula-2, Modula-3, Oberon. A pesar de todas las quejas aquí sobre problemas de dificultad y velocidad, ninguno de ellos parece tener grandes problemas.

Un buen punto de anidar comentarios de bloque es que puede comentar grandes porciones de código fácilmente (bueno, casi, a menos que tenga la secuencia final de comentario de bloque en una cadena constante).

Un método alternativo es anteponer un montón de líneas con la secuencia de inicio de comentarios de línea si tiene un editor que lo admita.

Haskell ha anidado comentarios en bloque, pero la mayoría de las personas no parecen darse cuenta o quejarse al respecto. Supongo que esto se debe a que las personas que no esperan comentarios anidados tienden a evitarlos, ya que esto sería un error léxico en otros idiomas.

El soporte de comentarios de bloque anidados complica el analizador, que es más trabajo y podría aumentar el tiempo de compilación. Supongo que no es una característica muy necesaria para un idioma, por lo que es mejor usar el tiempo y el esfuerzo en otras mejoras y optimizaciones.

En mi opinión, la simplicidad siempre es buena para diseñar cualquier cosa. Tenga en cuenta que es más fácil agregar una función que eliminarla. Una vez que permita comentarios anidados y haya programas que lo usen, no podrá eliminarlos sin romper la compatibilidad.

Una razón probable es que los comentarios anidados deben ser manejados por el analizador, ya que el sabor de las expresiones regulares comúnmente utilizadas en lexers no admite la recursividad. Los simples pueden ser eliminados como espacios en blanco por el lexer, por lo que son más fáciles de implementar de esa manera.

¿Quién sabe? Supongo que apoyar los comentarios anidados es más trabajo: tendrías que mantener una pila de algún tipo y complica la gramática del lenguaje.

Los comentarios anidados significan un trabajo extra para el analizador. Por lo general, cuando ve el comienzo de un comentario, ignora todo hasta el marcador de comentario final. Para admitir comentarios anidados, también debe analizar el texto en los comentarios. Sin embargo, el mayor problema es que un programador debe tener cuidado de cerrar todos los comentarios anidados correctamente o provocará errores de compilación. Implementar correctamente un compilador es algo que se puede hacer, pero realizar un seguimiento de los comentarios anidados como programador es bastante propenso a errores e irritante.