Perché la maggior parte dei linguaggi di programmazione non annidano i commenti dei blocchi?

Una cosa che nessuno ha ancora menzionato, quindi lo accennerò: Il desiderio di annidare i commenti spesso indica che il programmatore sta facendo male.

Innanzitutto, ammettiamo che l'unica volta in cui "il nesting" o "non nidificante" è visibile al programmatore è quando il programmatore scrive qualcosa strutturalmente come questo:

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

Ora, quando viene in pratica una cosa del genere? Certamente il programmatore non sta scrivendo commenti annidati che letteralmente assomigliano allo snippet sopra! No, in pratica quando annidiamo i commenti (o vorremmo poterli annidare), è perché vogliamo scrivere qualcosa del genere:

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

E questo è BAD. Questo non è un modello che (come designer di linguaggi) vogliamo incoraggiare! Il modo corretto per scrivere lo snippet sopra riportato è:

do_something();  /* do a thing */

Quel codice "sbagliato", quella falsa partenza o qualsiasi cosa fosse, non appartiene alla base del codice. Appartiene, nella migliore delle ipotesi, nella storia del controllo della sorgente. Idealmente, non avresti mai nemmeno scritto il codice sbagliato, giusto? E se il codice sbagliato stava servendo lì, avvisando i manutentori di non ripristinarlo per qualche motivo, beh, questo è probabilmente un lavoro per un commento del codice ben scritto e intenzionale cercando di esprimere "don" 't fare X' semplicemente lasciando un vecchio codice che fa X, ma commentato, non è il modo più leggibile ed efficace per impedire alle persone di fare X.

Tutto questo si riduce a una semplice regola empirica che potresti aver già sentito prima: Non commentare il codice. (la ricerca di questa frase diventerà una lotto of opinioni in agreement .)

Prima di chiedere: sì, lingue come C, C # e C ++ forniscono già al programmatore un altro strumento per "commentare" grandi blocchi di codice: #if 0 . Ma questa è solo una particolare applicazione del preprocessore C, che è uno strumento grande e utile a sé stante. In realtà sarebbe estremamente difficile e speciale-casey per un linguaggio che supporti la compilazione condizionale con #if e tuttavia non supporto #if 0 .

Quindi, abbiamo stabilito che i commenti nidificati sono rilevanti solo quando il programmatore sta commentando il codice; e abbiamo stabilito (tramite il consenso di molti programmatori esperti) che commentare il codice è una brutta cosa.

Per completare il sillogismo, dobbiamo accettare che i progettisti di linguaggi hanno interesse a promuovere le cose buone e scoraggiare le cose cattive (supponendo che tutto il resto sia uguale).

Nel caso di commenti annidati, tutto il resto è uguale - puoi tranquillamente ignorare le risposte con basso voto che affermano che l'analisi di% nidificato di co_de sarebbe in qualche modo "difficile" per il parser. (% Nidificato% co_de nidificato non è più difficile di% nidificato nidificato, che quasi ogni parser al mondo deve già gestire.)

Quindi, a parità di tutti gli altri, un disegnatore linguistico dovrebbe rendere facile per annidare commenti (cioè, commentare un codice), o difficile? Ricordare che commentare il codice è una brutta cosa.

Q.E.D.

Il testo della nota. Nota che se non permetti i commenti annidati, allora

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

è un "commento" fuorviante - equivale a

hello bar.txt */ world

(che è probabilmente un errore di sintassi). Ma se fai permetti i commenti nidificati, allora

hello /* foo/*.txt */ world

è un "commento" fuorviante - equivale a

hello

ma lascia il commento aperto fino alla fine del file (che di nuovo è quasi certamente un errore di sintassi). Quindi nessuno dei due modi è particolarmente meno incline a errori di sintassi non intenzionali. L'unica differenza sta nel modo in cui gestiscono l'antipattern intenzionale del codice commentato.

Poiché la maggior parte delle implementazioni utilizza fasi di lexing e parsing separate, e per lessicarle stanno usando semplici espressioni regolari. I commenti sono trattati come spazi bianchi - cioè, token ignorati, e quindi dovrebbero essere risolti interamente in un passaggio di lexing. L'unico vantaggio di questo approccio è la velocità di analisi. Numerosi svantaggi includono gravi limitazioni alla sintassi (ad esempio, la necessità di mantenere un set di parole chiave fisso, indipendente dal contesto).

È perfettamente possibile creare un lexer in grado di gestire i commenti nidificati. Quando si mangia uno spazio vuoto, quando vede /* può incrementare un contatore di profondità e decrementarlo quando vede */ , e si ferma quando la profondità è zero. Detto questo, ho eseguito molti parser e non ho mai trovato una buona ragione per i commenti da nidificare.

Se i commenti possono annidare, uno svantaggio è che è facile sbilanciare le loro estremità e, a meno che tu non abbia un editor di fantasia, può nascondere in modo invisibile il codice che presumi che sia lì.

Un lato positivo dei commenti che non si annidano è qualcosa del genere:

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

dove puoi facilmente commentare o inserire il codice rimuovendo o aggiungendo la prima riga: una modifica a una riga. Naturalmente, se il codice stesso contiene un commento, questo si interromperà, a meno che si permetta anche ai commenti in stile C ++ - stile // . Quindi è quello che tendo a fare.

Poiché nessun altro lo ha menzionato, elencherò alcune lingue che supportano i commenti annidati: Rexx, Modula-2, Modula-3, Oberon. Nonostante tutte le lamentele riguardo a problemi di difficoltà e velocità, nessuno di questi sembra avere grossi problemi.

Un buon punto dei commenti sui blocchi di nidificazione è che puoi commentare facilmente grandi porzioni di codice (beh, quasi, a meno che tu non abbia la sequenza di fine commento di blocco in una costante di stringa).

Un metodo alternativo è quello di anteporre una serie di linee alla sequenza di inizio dei commenti di riga se hai un editor che la supporta.

Haskell ha commenti nidificati sui blocchi, ma la maggior parte delle persone non sembra accorgersene o lamentarsi. Immagino che questo sia dovuto al fatto che le persone che non si aspettano commenti nidificati tendono a evitarli perché questo sarebbe un errore lessicale in altre lingue.

Il supporto dei commenti del blocco annidato complica il parser, che è più efficace e potrebbe aumentare il tempo di compilazione. Immagino che non sia una funzionalità molto necessaria per una lingua, quindi è meglio usare il tempo e gli sforzi su altri miglioramenti e ottimizzazioni.

Secondo me la semplicità è sempre una buona cosa nel progettare qualsiasi cosa. Tieni presente che è più semplice aggiungere una funzione piuttosto che rimuoverla. Una volta consentiti i commenti nidificati e non ci sono programmi che li utilizzano, non potrai eliminarli senza compromettere la compatibilità.

Un motivo probabile è che i commenti nidificati devono essere gestiti dal parser, poiché il sapore delle espressioni regolari comunemente usate nei lexer non supporta la ricorsione. Quelli semplici possono essere eliminati come spazio bianco dal lexer, quindi sono più semplici da implementare in questo modo.

Chi lo sa? Suppongo che il supporto dei commenti nidificati sia più efficace: dovresti mantenere uno stack di qualche tipo e perché complica la grammatica della lingua.

I commenti nidificati significano un lavoro extra per il parser. Di solito quando vedi l'inizio di un commento ignori tutto fino al marcatore di fine commento. Per supportare i commenti nidificati, devi analizzare anche il testo nei commenti. Il problema più grande, tuttavia, è che un programmatore deve fare attenzione a chiudere correttamente tutti i commenti nidificati o porterà a errori di compilazione. Implementare correttamente un compilatore è qualcosa che può essere fatto, ma tenere traccia dei commenti nidificati come programmatori è piuttosto soggetto a errori e fastidioso.