首先,功能默认为“未实现”.为了实现功能,有人必须考虑功能.然后我们必须设计它,指定它,实施它,测试它,记录它,找到它的运输工具,并把它出门.如果任何一件事情没有发生,你就不会得到这个功能.据我所知,这些功能都没有发生.

第二,功能的优点是基于他们的净收益 – 即它们对我们客户的总体利益,减去实施它们的总成本.这里有非常真实的“机会成本”.我们实施的每个功能都是几十个功能,我们没有预算.因此,功能不仅需要值得开展工作,否则他们必须比我们的功能请求列表中的成千上万个功能更有益处.这是一个很高的条件来实现;大多数功能从未实现.

要解释我的第三点,你需要知道一些语言如何处理.我们从源代码开始,并将其“引用”为“令牌” – 单词.在这一点上,我们知道每个字符是否是数字,字符串,关键字,标识符,注释,预处理器指令等的一部分.列表速度非常快;我们可以轻松地在击键之间重新列出一个文件.

然后我们采取一系列令牌,并将其解析成“抽象语法树”.这决定了代码的哪些部分是类,表达式,局部变量声明,名称,赋值等等.解析也很快,但不如词法快.我们做一些技巧,像跳过解析方法体,直到有人实际看着它们.

最后,我们采用抽象语法树并对其进行语义分析;这将确定给定的名称是指一个类型,一个局部变量,一个命名空间,一个方法组,一个字段等等.我们做“顶级”语义分析,确定程序的类型层次结构和“方法级”语义分析,以确定每个方法中每个表达式的类型. “顶级”语义分析相当快,任何单独的方法分析都很快,但是仍然难以在键盘之间进行全面的语义分析.

显然,我们需要对智能感知进行全面的语义分析,但是我们可以通过弄清楚你当前正在键入哪种方法,并且只进行顶级和该方法的语义分析.

但着色必须在整个文件上工作;你不能仅仅将颜色化到光标所在的方法.因此,着色必须非常快,所以在历史上我们主要是基于词汇信息进行着色.

偶尔,我们可以找出特殊的东西,如“这个东西可能是一种类型的”吗？给它一种不同的颜色.但是,当给定的实体说出一个方法组vs,比如说一个代表类型的领域时,需要一个相当丰富的语义分析级别,我们目前在每个按键上都不执行.

现在,我们可以在这里做些事情.我们可以更聪明地了解对令牌流的编辑,并且只对树的编辑部分进行语法和语义分析.现在我们正在对这个领域进行一些研究,但只是研究;它可能永远不会使其成为产品.