为什么解释/脚本语言很少有多行注释？答案

【问题标题】：Why do interpreted/scripting languages rarely have multi-line comments?为什么解释/脚本语言很少有多行注释？
【发布时间】：2011-05-20 18:34:22
【问题描述】：

在我所知道的解释语言（Python、Perl、R、bash）中，多行 cmets 似乎通常涉及对该语言的另一个特性（例如多行字符串）的一些误用。

解释器执行的解析类型是否有一些固有的东西使得多行 cmets 变得困难？它似乎与多行字符串没有显着差异。

【问题讨论】：

标签： parsing programming-languages comments interpreted-language

【解决方案1】：

不，脚本语言没有理由不支持多行 cmets。 JavaScript、Groovy、Lua、PHP、REXX、Smalltalk 和 Dart 都支持多行 cmets。

【讨论】：

【解决方案2】：

事实上，我确信在实现任何形式的多行 cmets 时没有任何意义（基于大多数解析器用来读取/执行脚本的方法）。在我个人看来，由于分发和解释，脚本最需要多行 cmets（大多数高级语言通常是编译的，而且只有一部分是开源的）。我知道 Lua 这种脚本语言确实提供了多行 cmets：

--[==[
COMMENT
]==]--

我敢肯定，许多语言不支持这一点只是侥幸。仅使用单行 cmets 创建多行注释通常是可以接受的。

//*****************************************\\
//**                                     **\\
//**            JOHN SMITH               **\\
//**        COPYRIGHT 2008-2011          **\\
//**                                     **\\
//*****************************************\\

很多人还会使用单行 cmets 创建一个很酷的图像 (ASCII ART)，使用注释字符开始图像（类似于上面显示的内容，其中 // 是注释字符/短语）。

【讨论】：

是的，但这种风格的评论比其他任何事情都更有效。我宁愿不向开发人员支付大笔资金，只是为了让这样的 cmets 看起来合适。 C 风格的多行 cmets 是更可取的 IMO
@drventure 非常非常真实！但是还有多少工作？您实际上需要多久添加一次多行注释？通常在代码 sn-p 的开头或大型应用程序中的一对。事实上，它可能只会为您节省一小部分时间，结果是一样的。它真的那么重要吗？我完全赞成多线 cmets，但我不会唠叨开发人员添加它们。希望有所帮助:)

【解决方案3】：

在 Python 中，我们只是使用多行字符串作为注释。

为什么会有两种语法？

【讨论】：

也许这适用于 Python，但 Perl 通常有两种方法胜于一种方法的理念。甚至 Python 通常也允许你以两种不同的方式做同样的事情，如果这样可以提高清晰度的话。（至少对我来说，分配给任何内容的字符串都不等同于注释。）
@Xodarap：我没有回答其他语言。我在回答 Python。您的问题可能过于宽泛，无法提供任何可能的答案，因为每种语言的答案可能不同。

【解决方案4】：

并非所有解释语言都缺少多行 cmets。例如，Ruby 就有。

我怀疑这主要是语言设计者的偏好。有些人只是不认为多线 cmets 是必要的功能。（现在许多代码编辑器都提供了使用单行 cmets 注释/取消注释大块代码的快捷方式。）

此外，多行 cmets 会增加解析器的复杂性。例如，它必须处理嵌套 cmets 的可能性。如果不需要，为什么还要增加复杂性？

【讨论】：

“如果不需要，为什么要增加复杂性”....但这就是多行 cmets 的全部意义所在，以消除必须处理多个单行 cmets 的复杂性。让编译器/解释器比开发人员更好地处理它。
我不认为多行 cmets 对任何人来说都更简单。脚本语言通常有 1 个字符，例如# 表示一行注释的开始。这很简单。在解析器中实现简单，程序员容易记住，非程序员也容易记住。简单地在 cmets 中使用 grep 或者如果您不在 cmets 中使用 grep 则省略）。无需增加复杂性而收效甚微。
@nos, @vocaro：多行 cmets 的语言通常不允许嵌套。所以多行 cmets 是规则的，因此等同于单行 cmets（即 CFG 中的终端）。我认为这不会使解析器变得更加复杂。
如果解析器不具备执行多行 cmets 的能力，那么它写得不好（对于解析器）。解析器的工作方式（好吧，无论如何）将使添加多行 cmets 变得非常容易（在合理范围内）。
除非您的多行 cmets 嵌套，否则解析器甚至不会看到它们，只会看到词法分析器。鉴于此，多行 cmets 的 lex 并不比单行 cmets 更难。

【解决方案5】：

我怀疑这只是有点语言偏见。 C 风格的多行 cmets 往往出现在 c-esque 语言中，但大多数其他语言没有等价物。

至于解析器本身。我没有理由认为解析器不实现多行 cmets，除了 lang 设计者不想这样做。大多数解析器生成器都可以轻松处理该构造。

【讨论】：

非 C 风格的语言也有多行 cmets：OCaml 有 (* .. *)，Haskell 有 {- .. -}...
确实如此，我相信有人提到过 Ruby 也是如此。但我几乎不会将 OCaml 或 Haskell 视为主流，而且我从未听说过它们被嵌入在任何情况下。但是，我完全有可能从未遇到过这样的项目。

【解决方案6】：

您的问题中有两个错误的假设。

第一个错误假设是“解释/脚本语言很少有多行 cmets”。你正遭受确认偏见的困扰。有带有单行 cmets 的编译语言（例如 Fortran、许多 Lisp 方言）和带有多行 cmets 的解释语言（例如 Perl、Python）。

第二个错误假设是涉及“滥用另一个功能”。语言作为一个整体设计得更好，如果存在的某些功能可以解决问题，则无需为多行 cmets 引入额外的功能。例如，在 Python 中，存在多行字符串，并且仅由字符串组成的指令是无操作的，因此多行字符串可以构成很好的 cmets。在 Perl 中，拥有多行 cmets 的一种方法是通过 Pod，一种文档格式； cmets 是一种文档，所以对于多行 cmets 使用=pod … =cut 是很自然的（多行字符串，通过here documents <<'EOF'; … EOF，是另一种方法）。

【讨论】：

哦，来吧。你是不是要板着脸坐在那里告诉我拉里沃尔排除了多行 cmets，因为那时Perl would have multiple ways of doing the same thing？
@Xodarap：当然。作为first virtue 的拥护者，Larry Wall 不会费心添加额外的功能，如果有其他方法可以获得它。