应该“显式关闭”命令行开关被认为是有害的吗？

Question

我们尽力遵循“标准”来处理参数和开关 从命令行。例如，默认情况下，我们采用 Posix2 和 GNU 标准用于命令行解析。

然而，由于我们的实用程序是跨平台的，并且我们希望可以通过跨平台脚本访问它们，因此我们也尝试变得“健壮”。因此，我们隐式地允许这两种形式：

  myutil --longname

  myutil /longname

这并非在所有情况下都是完美的，因为它可能有些含糊，例如 Posix 支持折叠“短”开关名称（这些是相同的）：

  myutil -abcd
  myutil -a -b -c -d
  myutil /a /b /c /d

（...我们不支持折叠Win 平台上的“短名称”，因为这是不明确的。）

另一个看起来有点奇怪的跨平台开关问题是“显式关闭”开关，其中尾随的“-”将开关显式标识为存在“turned off”：

  myutil -a-
  myutil --longname-
  myutil /a-
  myutil /longname-

这是明确的，所以我们认为它可以接受。 （“/a/”和“/longname/”的“显式关闭”看起来非常奇怪，所以我们使用了尾随的“-”作为“跨平台内部标准”。）

回想一下，这种历史上的“显式关闭”开关有时对于显式“关闭”默认为“打开”的值很有用，或者删除以前可能具有的开关已添加到正在组装的命令行中（例如，当从脚本组装命令行时，稍后决定“删除”先前添加的开关）。

然而，经过审查：这个“显式关闭”开关是否会被视为有害（不良形式）？

例如，如果实用程序默认为“-v”（--verbose) 作为“on”，我们可以有一个“否定开关”来将其关闭：

  myutil -v-

...或者，我们可以仅仅定义一个“<代码>-q” (--quiet) 作为“正向开关”，隐式将“on”变为“ Quiet”选项（这意味着“-v”开关的“off”）：

  myutil -q

当然，对于任何给定的实用程序，它将是 < em>冗余以支持“-v-”和“-q”形式，因为它们会做同样的事情。 此示例中，另一种选择是多个“详细级别”，其中一个级别为“安静”，但目标是说明显式禁用开关的“开/关”性质。）

（在 时间太长了，似乎“显式关闭”开关现在已经很大程度上失宠了（例如，在(Gnu)“命令行接口标准”。)

问题：开关的历史“显式关闭”是否应该被视为有害？

新的命令行实用程序是否应该支持“正开关”，而不是支持“负开关”或命令行选项到包含级别作为“良好形式”？）如果是这样，是否还有理由再支持“显式关闭”开关（对于今天编写的新实用程序）？

Answer 1

我从未听说过使用尾随 - 来关闭开关。在 UNIX 领域，它在前面加上 no-，如 --no-verbose 关闭 --verbose。至少，Ruby 的 OptionParser 直接支持这一点；不确定其他人的情况。

至于这种模式“有害”：绝对不会。拥有流畅的注释行界面总是好的。考虑更具破坏性的选项，例如覆盖现有文件的 --force。进一步考虑一种方案，用户可以为给定命令指定默认命令行选项。现在，如果她将 --force 配置为默认打开；如何根据具体情况将其关闭？

我们不希望她编辑配置文件来禁用 --force，因此我们提供 --no-force 来覆盖它。

可否定的长格式选项在其他脚本或 crontab 中也很有帮助，可以非常清楚地说明正在发生的事情：

3 * 1 * * awesome_script.sh --force my_files
0 * * * * awesome_script.sh --no-force my_files

必须维护此功能的可怜的系统管理员将不必去寻找 awesome_script.sh' s 文档（假设它甚至存在）来了解这里发生了什么。