Детализация синтаксической раскраски в Visual Studio

Question

Я без ума от раскраски синтаксиса, когда разные элементы исходного кода отображаются разными цветами.В настоящее время хорошая раскраска находится прямо там, где нужно, с правильным отступом, когда дело доходит до моей способности читать код.

Заглянув под Tools/Customize/Fonts and Colors, я вижу , что в некоторых случаях наблюдается тонкая детализация;вы можете присвоить разные цвета строкам, например, дословным строкам.

Но вот типичная строка кода на C #:

Controls.Add(combo);

Сейчас Controls, Add, and combo это все разные вещи, но все они отображаются одним и тем же цветом, потому что все они просто "идентификаторы".

Конечно, есть способ получить больше детализации, чем это?По крайней мере, методы окрашивания отличаются от объектов?

Answer 1

Несколько мыслей.

Во-первых, функции "не реализованы" по умолчанию. Чтобы реализовать функцию, кто-то должен подумать о ней. Затем мы должны спроектировать его, уточнить, реализовать, протестировать, задокументировать, найти для него транспортное средство и доставить его за дверь. Если что-то из этого не происходит, вы не получите эту функцию. Насколько я знаю, ничего из этого не произошло для этой функции.

Во-вторых, приоритетам функций являются их чистые выгоды, то есть их общая выгода для наших клиентов за вычетом наших общих затрат на их реализацию. Есть очень реальные "альтернативные издержки" в игре здесь. Каждая функция, которую мы ДЕЛАЕМ, - это десятки функций, на которые у нас нет бюджета. Таким образом, функции не только должны стоить работы, чтобы их реализовать, они должны быть БОЛЬШЕ выгоднее, чем любая из тысяч функций, которые мы получили в наших списках запросов функций. Это высокая планка для достижения; большинство функций никогда не достигают этого.

Чтобы объяснить мой третий момент, вам нужно немного узнать о том, как обрабатываются языки. Мы начнем с того, что возьмем исходный код и "lexing" это в "токены" - слова. На данный момент мы знаем, является ли каждый символ частью числа, строки, ключевого слова, идентификатора, комментария, директивы препроцессора и так далее. Лексирование невероятно быстро ; мы можем легко переделать файл между нажатиями клавиш.

Затем мы берем серию токенов и " parse " их в «абстрактное синтаксическое дерево». Это определяет, какие части кода являются классами, выражениями, объявлениями локальных переменных, именами, присваиваниями, чем угодно. Разбор также быстрый, но не такой быстрый, как lexing. Мы делаем некоторые трюки, например, пропускаем синтаксический анализ тел методов, пока кто-то на самом деле не смотрит на них.

Наконец, мы берем абстрактное синтаксическое дерево и делаем его семантический анализ; это определяет, относится ли данное имя к типу, локальной переменной, пространству имен, группе методов, полю и т. д. Мы делаем оба «верхнего уровня» семантический анализ, чтобы определить иерархию типов программы и «уровень метода»; семантический анализ, чтобы определить тип каждого выражения в каждом методе. " Верхний уровень " семантический анализ довольно быстр, и любой отдельный метод анализа довольно быстр, но все же сложно провести полный семантический анализ между нажатиями клавиш.

Очевидно, что нам нужно выполнить полный семантический анализ для intellisense, но мы можем уйти от выяснения того, какой метод вы вводите в данный момент, и только выполнить семантический анализ верхнего уровня и этого метода.

Но раскраска должна работать на весь файл; Вы не можете просто раскрасить метод, в котором сейчас находится курсор. Поэтому раскраска должна быть безумно быстрой, поэтому исторически мы раскрашивали в основном на основе лексической информации.

Иногда мы можем выяснить что-то особенное, например " эта вещь, вероятно, является типом? " чтобы придать ему другой цвет. Но для определения, когда данная сущность является, скажем, группой методов или, скажем, полем типа делегата, требуется довольно богатый уровень семантического анализа, уровень, который мы в настоящее время не выполняем при каждом нажатии клавиши.

Теперь есть вещи, которые мы можем сделать здесь. Мы могли бы быть умнее в понимании изменений в потоке токенов и выполнять только грамматический и семантический анализ в отредактированной части дерева. Сейчас мы проводим некоторые исследования в этой области, но это просто исследование; он может никогда не попасть в продукт.

Answer 2

Я полагаю, что плагин ReSharper обеспечивает некоторую улучшенную подсветку синтаксиса, о которой вы говорите.Также могут быть другие плагины, которые предоставляют то же самое (за меньшую стоимость), просто тот, который я использую.Я согласен, что подсветка синтаксиса очень полезна.ReSharper также делает некоторые приятные вещи, такие как выделяет мертвый код серым цветом, чтобы сделать его более очевидным, выделяет текущую строку и т.д.

-Дэниел