algorithm - 成员选择期间 "get best match"的 IntelliSense 规则

Question

首先，我终于把它变成了一个 wiki，但我相信一个“简单”、直截了当的答案是非常可取的，尤其是因为结果将为每个人定义一个统一的 IDE 行为。稍后会详细介绍。

过去，我曾在博客上讨论过 well-behaved member selection 意味着什么落下。如果您还没有阅读，请立即阅读。 :)

Visual Studio 2010 向 IntelliSense 选择过程添加了新功能，使事情……变得不那么简单。我相信我们可以从这些功能中利用强大的力量，但如果没有一套清晰的管理规则，这将非常困难。

在您回答之前，请记住这一点:这些规则应该允许与系统“协调一致”的人利用 IntelliSense 的强大功能，同时比其他解决方案提供的击键次数和时间更少。这不只是您习惯的东西 - 如果您像我一样长时间和频繁地使用一个系统，那么重新学习模式是微不足道的，而且它可以节省时间，因为它背后有一个很好的算法.

这里是可控轴:

• 过滤:“完整”列表包含当前位置允许的每个标识符或关键字，而不考虑光标所在的部分键入的文本。
• 排序:我们(至少 Visual Studio 用户)习惯于成员选择下拉列表按字母顺序排序。其他可能性是根据“相关性”等概念进行部分排序。
• 选择:根据当前键入的文本，我们可以选择一项作为“最佳匹配项”。选择状态是:
  • 没有选择项目
  • 被动选择:勾勒出一个项目，但按下 . , <space>或类似的东西不会在不使用箭头键的情况下填写:
  • 主动选择:选择一项，除非Esc或按下箭头键，.或 <space>等将自动完成该项目。

我之前的一套规则将操作限制在选择轴上。他们考虑到了:

• 键入的字符与 StartsWith 的列表项匹配操作(前缀匹配)，带有匹配是否区分大小写的变体。
• 以同一组字符开头的先前完成。

以下是额外可用且可能有用的，但并非所有都必须使用:

• CamelCase 匹配或 underscore_separation(“us”):长而富有表现力的标识符？没问题。
• 子字符串匹配:长前缀阻碍了您的选择速度？没问题。
• 摘要文本中可用的信息(如果可用):我反对这一点，但我必须承认它在 Firefox 地址栏中派上用场，所以你永远不知道。

您编写的规则应该按顺序处理轴(上面的粗体)。在我之前关于该主题的帖子中，规则非常简单，但额外的考虑可能会使它变得有点复杂。

1. 过滤
2. 排序
3. 选择

Answer 1

只是一个补充或评论......

IntelliSense 应该适应上下文。对于 Visual Studio，在只能使用特定类型或接口(interface)的子类型的地方，下拉列表应按这些进行过滤。

IList list = new(下拉所有实现 IList 的类型)- 不是所有可能的类型!