CLI模式/反模式的可用性

Question

哪些模式会影响或降低CLI界面的可用性？

例如,考虑使用ClearCase的CLI.CLI非常全面(+1),但它有几个明显的机会.最近,我想使用clearfsimport强制将文件小写成ClearCase .不幸的是,我结束了它的堂兄clearimport的文档.它可能看起来很轻微但是我花费的时间比我承认的要多.中间的变化让我感到高兴.

为什么提供这样几乎完全相同的功能？我认为有很多更好的选择

• clearimport -fs
• fsclearimport
• clear_fs_import
• clearimport_fs

任何东西都比他们的东西更好.我正在处理的代码是一个CLI,这种经历使我看到了自己的选择.我认为我已经涵盖了所有基础知识(标准帮助,长形式与简短形式,简短有意义的名称,提供示例,消除歧义,准确处理引号内的空格等).

有一些关于这个主题的文献.

也许错误的CLI与糟糕的API没什么不同.CLI在某种意义上是API的类型.目标自然是常见的::灵活性,可读性和完整性.CLI有几个因素可以区分CLI和典型的API.一个是CLI需要支持脚本化(可能多次参与一系列管道).另一个是自动完成和命名空间不以相同的方式存在.你并不总是有一个漂亮的彩色GUI为你做的东西.CLI必须直接在客户外部记录自己.最后,CLI的受众与标准API截然不同.我很感激您的任何见解.

Answer 1

我喜欢子命令模式,我最熟悉它是在命令行Subversion客户端中实现的.

svn [subcommand] [options] [files]

如果没有子命令,subversion会有太多不同的选择让我有效地记住它们,并且帮助系统将是一个痛苦的过程.

但是,如果我不记得任何特定的子命令是如何工作的,我可以输入:

svn help [subcommand]

......它只显示了帮助文档的相关部分.

Answer 2

如上所述，这种格式：

 [master verb] [subverb] [optionally, noun] [options]

有助于记住可用的命令。cvs、svn、Perforce、git，都遵循这一点。它提高了命令的可发现性，这是 CLI 的一个主要问题。这里出现的一个问题是主动词的选项与副动词的选项。IE，

cvs -d dir command bar

不同于

cvs command -d dir bar

这是 cvs 中令人困惑的情况，它svn通过允许以任何顺序指定选项来“修复”。您自己的解决方案可能会有所不同；如果您有充分的理由将选项传递给主动词，那么请注意开销。

考虑 API 可用性也是一个好主意，但要注意 CLI 命令中没有真正的输入，并且 CLI 命令“返回”有很多丰富的内容，因为您同时获得了返回代码和输出与. 一起工作。在 unixy/streams 世界中，输出通常比返回码重要得多。正确设置输出格式至关重要。另外，虽然很诱人，但我发现向 stdout 和 stderr 发送不同的内容并不总是有用；它让新手甚至中级用户感到困惑（因为在大多数情况下它们都会被转储到控制台），并且很少对高级用户有用。因此，除非确实需要它，否则我会避免它；对于（例如）某人来说，很容易对为什么命令的输出在错误情况下是“”感到非常困惑，只是因为程序员很好地将错误转储到了 stderr。

设计中的另一个问题是“下一步”问题。在 GUI 中，用户接下来的步骤由可用的按钮、菜单等详细说明。在 CLI 中，用户接下来可以逐字键入任何命令，并将任何命令通过管道传递给任何其他命令。（或者至少尝试一下。）我设计命令来给出提示（在帮助或输出中），说明典型工作流程中可能采取的后续步骤。

另一个好的模式是允许用户自定义输出。虽然用户可以使用cut、sort等来定制输出，但能够指定格式字符串会放大命令的实用性。我在这里引用的示例是top，它可以让您告诉它您想要哪些列。