用户界面

>命令行选项：allow尽可能多有默认值。
>没有任何具有超过2个选项的命令的位置参数。
>有可读选项名称。如果命令行的长度是非交互式调用的一个问题(例如，一些未命名的旧shell在命令行上有短限制)，则提供短别名 – GetOpt :: Long允许轻松。
>至少，在“-help”消息中打印所有选项的默认值。

更好的是，打印所有选项的“当前”值(例如，如果参数和值与“-help”一起提供，帮助消息将从命令行打印参数的值)。这样，人们可以组装命令行字符串用于复杂的命令，并在实际运行之前通过附加“-help”来验证。
>遵循Unix标准约定退出与非零返回代码iff程序终止与错误。
>如果你的程序可能产生有用的(例如值得捕获/ grepping / whatnot)输出，请确保任何错误/诊断消息去STDERR，以便它们是容易分离。
>理想情况下，允许用户通过命令行参数指定输入/输出文件，而不是强制“<” /“>”重定向 – 这允许更简单的生活给需要使用您的命令构建复杂的管道的人。同上错误消息 – 有logfile选项。
>如果命令有副作用，有一个“whatif / no_post”选项通常是一个很好的主意。

实施

>如前所述，不要重新发明车轮。使用标准命令行参数处理模块 – MooseX :: Getopt或Getopt :: Long
>对于Getopt :: Long，将所有参数分配给单个散列而不是单个变量。许多有用的模式包括将CLI args散列传递给对象构造函数。
>确保您的错误消息清晰且内容丰富…例如包括“$！”在任何IO相关的错误消息。值得花费额外的1分钟和2行在代码中有一个单独的“文件未找到”与“文件不可读”错误，而不是在生产紧急情况下花费30分钟，因为一个不可读的文件错误被误诊生产操作为“无输入文件” – 这是一个现实生活的例子。
>不是真正的CLI特定，但验证所有参数，最好是在得到它们后。
CLI不允许像webapps一样的“前端”验证，所以要超级额外的警惕。
>如上所述，模块化业务逻辑。除了已经列出的其他原因，我不得不重新实现一个现有的CLI工具作为一个网络应用程序的大量 – 而不是那么困难，如果逻辑已经是一个正确设计的perm模块。

有趣的链接

CLI Design Patterns – I think this is ESR’s

我会尝试添加更多的子弹，因为我记得他们。