哪些模式会影响或降低CLI界面的可用性？
作为示例，请考虑使用ClearCase的CLI。 CLI非常全面（+1），但它有几个明显的机会。最近，我想使用clearfsimport强制将文件小写成ClearCase。不幸的是，我结束了它的堂兄clearimport的文档。它可能看起来很轻微但是我花费的时间比我承认的要多。中间的变化让我感到高兴。
为什么要提供这样几乎完全相同的功能？我认为有很多更好的选择
clearimport -fs fsclearimport clear_fs_import clearimport_fs 任何东西都会比他们的东西更好。我正在使用的代码 IS 一个CLI，这种体验让我看到了自己的选择。我认为我已经涵盖了所有基础知识（标准帮助，长形式与简短形式，简短有意义的名称，提供示例，消除歧义，准确处理引号内的空格等）。
此主题有一些literature。
也许错误的CLI与bad API没什么不同。 CLI在某种意义上是API的类型。目标自然是常见的::灵活性，可读性和完整性。 CLI有几个因素可以区分CLI和典型的API。一个是CLI需要支持脚本化（可能多次参与一系列管道）。另一个是自动完成和命名空间不以相同的方式存在。你并不总是有一个漂亮的彩色GUI为你做的东西。 CLI必须直接在客户外部记录自己。最后，CLI的受众与标准API截然不同。我很感激您的任何见解。
答案 0 :(得分：9)
我喜欢子命令模式，我最熟悉它是在命令行Subversion客户端中实现的。
svn [subcommand] [options] [files]
如果没有子命令，subversion会有太多不同的选择让我有效地记住它们，并且帮助系统将是一个痛苦的过程。
但是，如果我不记得任何特定的子命令是如何工作的，我只需输入：
svn help [subcommand]
...它只显示了帮助文档的相关部分。
答案 1 :(得分：4)
如上所述，这种格式：
[master verb] [subverb] [optionally, noun] [options]
在记住可用的命令方面很好。 cvs，svn，Perforce，git，都坚持这一点。它提高了命令的可发现性，这是一个主要的CLI问题。这里出现的一个问题是master-verb与subverb选项的选项。即，
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，它可以让您告诉它您想要哪些列。