设计命令行参数的良好习惯是什么？

在开发应用程序时，我开始怀疑-我应该如何设计命令行参数？

很多程序都使用公式是这样-argument value或/argument value。我想到的解决方案是argument:value。我认为这是很好的，因为没有空格就无法将值和参数弄乱。同样，很容易将字符串从左:字符的第一个字符拆分为两个。

我的问题是：

1. 流行的-argument value公式是否比argument:value（更易读，更容易编写，没有错误，更易于专家开发人员理解）更好？
2. 在设计命令行参数时，是否应该遵循一些众所周知的规则（如果可行，可以的话）？

要求提供更多详细信息，我将提供它。但是，我认为它们不应影响答案。问题在于总体上的良好习惯。我认为它们对于各种应用程序都是相同的。

我们正在开发一个将在公共场所（触摸图腾，桌子）使用的应用程序。应用程序是使用Qt Quick 5（C ++，QML，JS）编写的。设备将安装Windows 8.1 / 10。我们将提供前端界面来管理设备。但是，某些高级管理员可能希望自己配置应用程序。从业务的角度来看这不是很重要，但是正如我同意Kilian Foth所说的那样，我不希望我的应用程序给用户带来麻烦。在互联网上找不到我想要的内容。

对于更高级的Stack Exchange用户：我希望这个问题笼统。也许它符合社区Wiki的资格（我不知道是否可以将现有问题转换为答案）。因为我希望这个问题与操作系统和编程语言无关，所以这里出现的答案对于其他开发人员来说可能是一个宝贵的教训。

在POSIX系统（例如Linux，MacOSX）上，至少对于可能在Shell终端中启动的程序（例如其中的大多数），我建议使用GNU编码约定（还列出了常用的参数名称），并查看POSIX实用程序指南，即使是专有软件：

• 总是处理--version和--help（甚至/bin/true接受它们！）。我诅咒软件作者不理解--help，我讨厌他们（因为这prog --help 是我在新程序上尝试的第一个命令）！通常--help可以缩写为-h

• 使--help消息列出所有选项（除非您有太多的选择...在这种情况下，列出最常见的选项并显式引用某些man页面或某些URL）和选项的默认值，并且可能是重要的（且特定于程序） ） 环境变量。在选项参数错误时显示这些选项列表。

• 接受-a简短的论点（单字母）并具有一些等效项--long-argument，因此-a2 --long-argument=2，--long-argument 2;; 当然，您可以（对于很少使用的选项）使用一些--only-long-argument名称；对于没有额外选项的模态参数，-cf通常会以-c -f等方式处理，因此您的-argument:value建议很奇怪，我不建议您这样做。

• 使用GLIBC getopt_long或更好（例如argp_parse，在OCaml中是Arg模块，...）

• 经常使用-标准输入或输出（如果你不能做到这一点，处理/dev/stdin和/dev/stdout甚至在一些操作系统没有他们）

• 通过重用它们的大多数选择约定来模仿相似程序的行为；特别是-n对于空转（àla make），-h寻求帮助，-v冗长等...

• 使用--作为选项-文件或其他参数之间的分隔符

• 如果您的程序用于isatty测试而不是stdin是终端（并且在这种情况下表现为“交互”），则提供一个选项来强制非交互模式，同样，如果您的程序具有GUI界面（并getenv("DISPLAY")在X11桌面上进行测试），但也可以用于批处理或命令行。

• 一些程序（例如gcc）接受间接参数列表，所以@somefile.txt从中读取程序参数的含义也是如此somefile.txt。当你的程序可能会接受一个非常大的很多参数，这可能是有用的（超过你的内核ARG_MAX）

顺便说一句，您甚至可以为程序和常规shell（如bash或zsh）添加一些自动完成功能

一些旧的Unix命令（例如dd，甚至sed）具有奇怪的命令参数以实现历史兼容性。我建议不要遵循他们的坏习惯（除非您对它们进行了一些改进）。

如果你的软件是一系列相关的命令行程序的，采取从灵感混帐（这你一定作为开发工具使用），它接受git help和git --help并有许多gitsubcommand和gitsubcommand--help

在极少数情况下，您可能还会使用argv[0]（通过在程序上使用符号链接），例如，bash由于rbash具有不同的行为（受限制的 shell）而被调用。但是我通常不建议这样做；如果可以使用shebang将您的程序用作脚本解释器，即#!在execve（2）解释的第一行上，那可能就有意义。如果您使用这些技巧，请确保将它们记录下来，包括在--help消息中。

请记住，在POSIX上，外壳程序会遍历参数（在运行程序之前！），因此请避免在需要转义外壳程序的选项中要求使用字符（例如*或$或~）。

在某些情况下，您可以在软件中嵌入诸如GNU guile或Lua之类的解释器（如果您不是编程语言专家，请避免发明自己的图灵完整脚本语言）。这会对软件的设计产生深远的影响（因此应尽早考虑！）。然后，您应该可以轻松地将某些脚本或某些表达式传递给该解释器。如果您采用这种有趣的方法，请谨慎设计软件及其解释的原语；您可能会有一些奇怪的用户为您的事情编写大型脚本。

在其他情况下，您可能希望让高级用户将其插件加载到您的软件中（使用动态加载技术àla dlopen＆dlsym）。同样，这是一个非常重要的设计决策（因此，请谨慎定义和记录插件接口），并且您需要定义一个约定以将程序选项传递给这些插件。

如果您的软件比较复杂，请使其接受某些配置文件（附加或替换程序参数），并且可能有某种方法可以测试（或只是解析）这些配置文件而无需运行所有代码。例如，邮件传输代理（例如Exim或Postfix）非常复杂，能够“半干”运行它（例如观察它如何处理某些给定的电子邮件地址而不实际发送电子邮件）很有用。

^{注意，这/option是Windows或VMS。在POSIX系统上这太疯狂了（因为文件层次结构/用作目录分隔符，并且因为shell会进行globbing）。我所有的答案主要是针对Linux（和POSIX）的。}

PS：如果可能的话，使您的程序成为免费软件，您会从某些用户和开发人员那里得到改进（添加新程序选项通常是添加到现有免费软件中最容易的事情之一）。此外，你的问题取决于很多的目标受众：青少年游戏或奶奶的浏览器可能并不需要相同种类和比一个编译器选项量，或用于数据中心的系统管理员的网络检查员，或微处理器CAD软件建筑师或桥梁设计师。熟悉编程和脚本的工程师可能比祖母更喜欢具有许多可调选项，并且可能希望能够在没有X11的情况下运行您的应用程序（也许正在crontab工作）。

数据格式约定很流行的事实是它的优点。

您可以轻松地看到，使用=或：或什至''作为分隔符是微不足道的差异，这些差异可以由计算机轻松转换为彼此。这将是一个很大的努力，是任何一个人记住“现在看，这样做是不常用的程序划定事情:或=？嗯...”

换句话说，出于对上帝的爱，在没有令人信服的理由的情况下，请不要背离极其根深蒂固的惯例。人们会把您的程序记为“具有奇怪而烦人的cmdline语法的程序”，而不是“保存了我大学论文的程序”。

用外行的话

在罗马做到入乡随俗。

• 如果您的CLI应用程序适用于Linux / Unix，请使用-p value或--parameter value约定。Linux具有用于轻松解析此类参数和标志的工具。

我通常会这样：

while [[ $# > 0 ]]
do
key="$1"
case $key in
    --dummy)
    #this is a flag do something here
    ;;
    --audit_sessiones)
    #this is a flag do something here
    ;;
    --destination_path)
    # this is a key-value parameter
    # the value is always in $2 , 
    # you must shift to skip over for the next iteration
    path=$2
    shift
    ;;
    *)
    # unknown option
    ;;
esac
shift
done

• 如果您的CLI应用程序适用于Windows，请使用/flag和/flag:value约定。

• 像Oracle这样的某些应用程序却没有使用。Oracle实用程序使用PARAMETER=VALUE。

• 我想做的一件事是，除了在命令行中接受参数外，还提供使用parfile的选项，parfile是一个键值对文件，以避免冗长的参数链。为此，您应该提供一个附加--parfile mifile.par参数。显然，如果--parfile使用，则所有其他参数都将被丢弃，以支持parfile中的内容。

• 另一个建议是允许使用某些自定义环境变量，例如，设置环境变量MYAPP_WRKSPACE=/tmp将使其不必始终设置--wrkspace /tmp。

• 在Linux中，不要忘了添加参数auto-completion，这意味着用户可以键入一半的开关，TAB然后按一下，然后shell会为他们完成它。

尚未出现的一件事：

尝试从命令行参数向上设计软件。含义：

在设计功能之前，请设计用户界面。

这样，您就可以尽早深入分析边缘案例和常见案例。当然，您仍然要对外部和内部进行抽象，但是与只编写所有代码然后对它进行CLI抨击相比，它会产生更好的结果。

此外，请查看docopt（http://docopt.org/）。

docopt在许多语言中都提供了很大的帮助，尤其是对于python而言，它的使用非常有限，像argparse这样的用户不利参数解析器仍然被认为是“ OK”。无需定义解析器，子解析器和条件字典，您只需定义语法帮助即可完成其余工作。

已经提供了一些有价值的评论（@ Florian，Basile），但让我补充一下……OP说，

我们将提供前端界面来管理设备。但是，某些高级管理员可能希望自己配置应用程序

还要说明：

我不希望这个问题与平台或语言有关

您必须考虑目标受众的高级管理员。他们通常在什么平台上工作-Win / Unix / Mac？您的应用在什么平台上运行？遵循已为该平台建立的任何CLI约定。您的“高级”管理员是否需要/需要基于GUI的工具？

您希望界面在内部和与其他管理工具保持一致。我不想停下来想一想是cmd -p <arg>or cmd -p:<arg>or cmd /p <arg>。我需要引号'cos那里有空格吗？我可以cmd -p <val1> <val2>还是cmd -p <val1> -p <val2>针对多个目标？它们是特定于订单的吗？可重载？不cmd -p2 <arg> -p1 <arg>工作吗？是否ls -l -r -t dir1 dir2== ls -trl dir1 dir2？

对于我的Unix管理工具，我始终牢记Heiner's Shelldorado提供的指导以及提到的其他参考。

与设计CLI一样重要的是要确保您的应用程序设计为可以使用与GUI相同的命令行参数-即：GUI中没有业务逻辑，或者使用从GUI和CLI调用的通用命令。

实际上，大多数基于UNIX的管理工具最初都是作为命令行工具设计的，并且提供的GUI只是简化了“填充”命令行选项的工作。这种方法可以实现自动化，响应文件的使用等，以及不需动手的管理（对我而言，工作量更少！）

作为使用此方法的经典工具集，它是Tcl / Tk。不建议您切换工具；只需考虑以下设计方法：首先将基于GUI的管理应用程序编写为命令行工具即可；然后为方便起见将GUI放在最上面。在某些时候，如果您必须进行多个配置并一遍又一遍地重新输入相同的选项，并且可能会发现GUI是一种痛苦（并且容易出错），并且您会寻找一种自动化的方法。

请记住，无论如何，您的管理员可能都必须在正确的框中键入正确的值，所以您需要付出多少努力才能使用GUI？