成员选择期间“获得最佳匹配”的IntelliSense规则

Question

首先，我最终将其设为维基，但我认为非常需要一个“简单”直截了当的答案，特别是因为结果将为每个人定义统一的IDE行为。更多关于简单的事情。

过去，我曾在博客中介绍了well-behaved member selection下拉的含义。如果您还没有阅读，请立即阅读。 ：）

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

在您回答之前，请记住：这些规则应该允许有人与系统“协调”，利用IntelliSense功能，减少击键次数，减少其他解决方案提供的时间。这是不只是你习惯的东西 - 如果你像我一样经常使用系统，那么重新学习模式就可以节省时间，以便在它背后有一个很好的算法

以下是可控轴：

• 过滤：“完整”列表包含当前位置允许的每个标识符或关键字，而不考虑光标所在的部分类型文本。
• 排序：我们（至少是Visual Studio用户）用于按字母顺序排序的成员选择下拉列表。其他可能性是通过某些概念“相关性”等进行部分排序。
• 选择：根据当前输入的文字，我们可以选择一个项目作为“最佳匹配”。选择状态是：
  • 未选择任何项目
  • 被动选择：概述了一个项目，但按.，<space>或类似内容将不会使用箭头键填写它：
  • 有效选择：选择了一个项目，除非按下Esc或箭头键，否则.或<space>等会自动完成该项目。

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

• 与StartsWith操作（前缀匹配）的列表项匹配的字符类型，以及匹配是否区分大小写的变体。
• 以同一组字符开头的先前完成。

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

• CamelCase匹配或underscore_separation（“我们”）：长而富有表现力的标识符？不是问题。
• 子串匹配：长前缀阻碍您的选择速度？不是问题。
• 摘要文本中提供的信息（如果有）：我倾向于此，但我必须承认它在Firefox地址栏中派上用场，所以你永远不会知道。

您编写的规则应按顺序寻址轴（上面以粗体显示）。在我之前关于这个主题的帖子中，规则非常简单，但是额外的考虑可能会使这更加复杂。

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

Answer 1

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

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

IList list = new（删除所有实现IList的类型） - 并非所有可能的类型！