perl - 在 Perl 中实现 CLI 工具的最佳实践是什么？

Question

我正在使用 Perl 实现 CLI 工具。我们可以遵循哪些最佳实践？

Answer 1

作为前言，我花了 3 年时间为一家大型金融公司设计并实现了一个相当复杂的 Perl 命令行工具集。以下想法基本上是我们团队设计指南的一部分。

用户界面

1. 命令行选项:允许尽可能多的有默认值。

2. 任何具有 2 个以上选项的命令都没有位置参数。

3. 具有可读的选项名称。如果命令行长度是非交互式调用的一个问题(例如，一些未命名的旧 shell 对命令行有较短的限制)，请提供短别名 - GetOpt::Long 可以轻松实现这一点。

4. 至少，在“-help”消息中打印所有选项的默认值。

   更好的是，打印所有选项的“当前”值(例如，如果与“-help”一起提供参数和值，则帮助消息将从命令行打印参数的值)。这样，人们可以为复杂的命令组装命令行字符串，并在实际运行之前通过附加“-help”来验证它。

5. 遵循 Unix 标准约定，如果程序因错误终止，则以非零返回代码退出。

6. 如果您的程序可能会产生有用的(例如值得捕获/grepping/诸如此类的)输出，请确保所有错误/诊断消息都发送到 STDERR，以便它们可以轻松分离。

7. 理想情况下，允许用户通过命令行参数指定输入/输出文件，而不是强制“<”/“>”重定向 - 这使得需要使用命令构建复杂管道的人们的生活变得更加简单。错误消息也是如此 - 有日志文件选项。

8. 如果命令有副作用，那么使用“whatif/no_post”选项通常是一个非常好的主意。

实现

1. 如前所述，不要重新发明轮子。使用标准命令行参数处理模块 - MooseX::Getopt 或 Getopt::Long

2. 对于 Getopt::Long，将所有参数分配给单个散列，而不是单个变量。许多有用的模式包括将 CLI 参数哈希传递给对象构造函数。

3. 确保您的错误消息清晰且内容丰富......包括“$!”在任何与 IO 相关的错误消息中。在代码中花费额外的 1 分钟和 2 行来获得单独的“文件未找到”与“文件不可读”错误是值得的，而不是在生产紧急情况下花费 30 分钟，因为生产误诊了不可读的文件错误“无输入文件”操作 - 这是一个现实生活中的示例。

4. 并非真正特定于 CLI，但验证所有参数，最好是在获取参数后立即验证。CLI 不允许像 Web 应用程序那样进行“前端”验证，因此要格外警惕。

5. 如上所述，模块化业务逻辑。除了已经列出的其他原因之外，我必须将现有 CLI 工具重新实现为 Web 应用程序的次数非常多 - 如果逻辑已经是正确设计的 Perm 模块，那么这并不困难。

有趣的链接

CLI Design Patterns - I think this is ESR's

我会尝试添加更多我记得的项目符号。