Visual Studio中语法着色的粒度

Question

我对语法着色很着迷，其中不同的源代码元素以不同的颜色显示。如今，在我阅读代码的能力方面，良好的色彩就是适当的缩进。

看看工具/自定义/字体和颜色，我可以看到在某些情况下有细粒度;例如，你可以为字符串和逐字字符串赋予不同的颜色。

但这是典型的C＃代码：

Controls.Add(combo);

现在 Controls，Add和combo 都是不同类型的东西，但它们都以相同的颜色呈现，因为它们都只是'标识符'。

当然有一种方法可以获得更多的粒度吗？至少颜色方法与对象不同？

Answer 1

一些想法。

首先，功能“未实现”。默认情况下。为了实现功能，有人必须考虑该功能。然后我们必须设计它，指定它，实现它，测试它，记录它，找到它的运输车辆，并把它拿出门。如果这些事情中的任何一个没有发生，你就不会得到这个功能。据我所知，这个功能没有发生过这个功能。

其次，根据其净收益（即对客户的总体收益减去实施它们的总成本）对功能进行优先排序。存在非常真实的“机会成本”。在这里玩。我们实施的每项功能都是我们没有预算的数十种功能。因此，功能不仅值得让它们发生，它们必须比我们在功能请求列表中获得的数千种功能中的任何功能更有益。这是一个很高的目标;大多数功能都无法实现。

要解释我的第三点，您需要了解一下语言的处理方式。我们首先采用源代码和“lexing”。它变成了“令牌” - 单词。此时，我们知道每个字符是否是数字，字符串，关键字，标识符，注释，预处理程序指令等的一部分。 Lexing 非常快;我们可以轻松地在按键之间重新调用文件。

然后，我们采用一系列令牌并“解析”。它们变成了“抽象语法树”。这决定了代码的哪些部分是类，表达式，局部变量声明，名称，赋值等等。解析也很快，但没有lexing快。我们做了一些技巧，比如跳过解析方法体，直到有人真正看到它们。

最后，我们采用抽象语法树并对其进行语义分析;这确定给定名称是指类型，局部变量，命名空间，方法组，字段等。我们同时做到“顶级”语义分析，用于确定程序的类型层次结构，以及“方法级别”。语义分析，确定每个方法中每个表达式的类型。 “顶级”语义分析非常快，任何单独的方法分析都非常快，但仍然很难在击键之间进行完整的语义分析。

显然我们需要对智能感知进行全面的语义分析，但是我们可以找出你当前输入的方法，并且只对顶层和那个方法进行语义分析。

但是着色必须适用于整个文件;你不能只是将光标碰巧的方法着色。因此，着色必须非常快，所以在历史上我们主要基于词汇信息进行着色。

偶尔我们可以找出特殊的东西，比如“这个东西可能是一种类型吗？”给它一个不同的颜色。但是，弄清楚某个给定实体何时，例如，一个方法组vs，比如一个委托类型的领域，需要一个非常丰富的语义分析级别，这是我们目前在每次击键时都不会执行的级别。

现在，我们可以在这里做些事情。我们可以更聪明地理解对令牌流的编辑，并且只对树的编辑部分重新执行语法和语义分析。我们现在正在对这个领域进行一些研究，但这只是研究;它可能永远不会真正进入产品。

Answer 2

我相信ReSharper插件提供了一些像你所说的增强语法高亮显示。可能还有其他插件提供相同的东西（成本更低），这就是我使用的插件。我同意语法高亮非常有用。 ReSharper还做了一些很好的事情，比如灰色的死代码使它更明显，突出显示当前行等等。

-Daniel