Une chose que personne n'a encore mentionnée, je vais donc la mentionner: le désir d'imbriquer des commentaires indique souvent que le programmeur fait mal.
Tout d'abord, convenons que le seul moment où "l'imbrication" ou "non imbrication" est visible pour le programmeur est lorsque le programmeur écrit quelque chose de structurellement comme ceci:
do_something();
/* comment /* nested comment */ more comment */
do_something_else();
Maintenant, quand une telle chose arrive-t-elle dans la pratique? Le programmeur n'écrira certainement pas des commentaires imbriqués qui ressemblent littéralement à l'extrait ci-dessus! Non, en pratique lorsque nous imbriquons des commentaires (ou souhaitons pouvoir les imbriquer), c'est parce que nous voulons écrire quelque chose comme ceci:
do_something(); /* do a thing */
/* [ajo] 2017-12-03 this turned out to be unnecessary
do_something_else(); /* do another thing */
*/
Et c'est MAUVAIS. Ce n'est pas un modèle que nous (en tant que concepteurs de langues) voulons encourager! La bonne façon d'écrire l'extrait ci-dessus est:
do_something(); /* do a thing */
Ce "mauvais" code, ce faux départ ou quoi que ce soit, n'appartient pas à la base de code. Il appartient, au mieux, à l'histoire du contrôle de source. Idéalement, vous n'écririez jamais le mauvais code pour commencer, non? Et si le mauvais code servait un but là-bas, en avertissant les responsables de ne pas le rétablir pour une raison quelconque, eh bien, c'est probablement un travail pour un commentaire de code bien écrit et intentionnel. Essayer d'exprimer "ne faites pas X" en laissant simplement dans un ancien code qui fait X, mais commenté, n'est pas le moyen le plus lisible ou efficace d'empêcher les gens de faire X.
Tout cela se résume à une simple règle empirique que vous avez peut-être déjà entendue auparavant: ne commentez pas le code. ( La recherche de cette phrase tournera un grand nombre d' opinions en accord .)
Avant de vous demander: oui, langages tels que C, C # et C ++ donnent déjà le programmeur un autre outil pour « commentaire » de gros blocs de code: #if 0
. Mais ce n'est qu'une application particulière du préprocesseur C, qui est un outil important et utile à part entière. Il serait en fait extrêmement difficile et spécial pour un langage de prendre en charge la compilation conditionnelle avec #if
et pourtant pas de support #if 0
.
Nous avons donc établi que les commentaires imbriqués ne sont pertinents que lorsque le programmeur commente du code; et nous avons établi (via le consensus de nombreux programmeurs expérimentés) que commenter le code est une mauvaise chose.
Pour compléter le syllogisme, nous devons accepter que les concepteurs de langage ont intérêt à promouvoir les bonnes choses et à décourager les mauvaises choses (en supposant que tout le reste est égal).
Dans le cas des commentaires imbriqués, tout le reste est égal - vous pouvez ignorer en toute sécurité les réponses à faible vote qui prétendent que l'analyse imbriquée /*
serait en quelque sorte «difficile» pour l'analyseur. (Les imbriqués /*
ne sont pas plus difficiles que les imbriqués (
, que presque tous les analyseurs du monde doivent déjà gérer.)
Donc, toutes choses étant égales par ailleurs, un concepteur de langage devrait-il faciliter l' imbrication des commentaires (c.-à-d. Commenter le code), ou difficile? Rappelons que commenter le code est une mauvaise chose.
QED
Note de bas de page. Notez que si vous n'autorisez pas les commentaires imbriqués,
hello /* foo*/bar.txt */ world
est un "commentaire" trompeur - il équivaut à
hello bar.txt */ world
(ce qui est probablement une erreur de syntaxe). Mais si vous faites autoriser les commentaires imbriqués, puis
hello /* foo/*.txt */ world
est un "commentaire" trompeur - il équivaut à
hello
mais laisse le commentaire ouvert jusqu'à la fin du fichier (ce qui est certainement une erreur de syntaxe). Donc, aucune des deux méthodes n'est particulièrement moins sujette aux erreurs de syntaxe involontaires. La seule différence réside dans la façon dont ils gèrent l' anti-motif intentionnel du code mis en commentaire.