Granularité de la coloration syntaxique dans Visual Studio

Question

Je suis fou de coloration syntaxique, où différents éléments de code source sont affichés dans différentes couleurs. De nos jours, la bonne coloration est au rendez-vous avec l'indentation appropriée pour ma capacité à lire le code.

En regardant sous Outils / Personnaliser / Polices et couleurs , je constate que dans certains cas, la granularité est fine. vous pouvez donner différentes couleurs aux chaînes, et des chaînes textuelles, par exemple.

Mais voici une ligne typique de code C #:

Controls.Add(combo);

Maintenant, Contrôles, Ajouter et Combo sont tous différents, mais ils sont tous restitués dans la même couleur, car ils ne sont que des "identificateurs".

Il existe sûrement un moyen d’obtenir plus de granularité que cela? Au moins les méthodes de couleur différemment des objets?

Answer 1

Quelques réflexions.

Premièrement, les fonctionnalités ne sont "pas implémentées". par défaut. Pour qu'une fonctionnalité soit implémentée, quelqu'un doit y penser. Ensuite, nous devons le concevoir, le spécifier, le mettre en œuvre, le tester, le documenter, trouver un véhicule d’expédition et le faire sortir. Si aucune de ces choses ne se produit, vous n'obtenez pas la fonctionnalité. Autant que je sache, AUCUNE de ces choses ne s'est produite pour cette fonctionnalité.

Deuxièmement, les fonctionnalités sont classées par ordre de priorité en fonction de leurs avantages nets, c’est-à-dire de leurs avantages pour nos clients, diminués de nos coûts totaux de mise en œuvre. Il existe de très réels "coûts d'opportunité". en jeu ici. Toutes les fonctionnalités que nous mettons en œuvre sont des dizaines de fonctionnalités pour lesquelles nous n'avons pas de budget. Ainsi, les fonctionnalités ne doivent pas seulement valoir la peine d'être travaillées, elles doivent être PLUS avantageuses que les milliers de fonctionnalités que nous avons sur nos listes de demandes de fonctionnalités. C'est une barre haute à atteindre; la plupart des fonctionnalités n'y parviennent jamais.

Pour expliquer mon troisième point, vous devez en savoir un peu plus sur le traitement des langues. Nous commençons par prendre le code source et "lexing". il en " jetons " -- mots. À ce stade, nous savons si chaque caractère fait partie d'un nombre, d'une chaîne, d'un mot clé, d'un identificateur, d'un commentaire, d'une directive de préprocesseur, etc. Lexing est incroyablement rapide ; on peut facilement re-lexer un fichier entre les frappes.

Nous prenons ensuite la série de jetons et "analysons". les transformer en un "arbre de syntaxe abstraite". Cela détermine quelles parties du code sont des classes, des expressions, des déclarations de variables locales, des noms, des assignations, etc. L'analyse est également rapide, mais pas aussi rapide que lexer. Nous faisons quelques astuces, comme sauter l'analyse des corps de méthodes jusqu'à ce que quelqu'un les regarde réellement.

Enfin, nous prenons l’arbre de syntaxe abstrait et effectuons une analyse sémantique dessus; cela détermine si un nom donné fait référence à un type, une variable locale, un espace de nom, un groupe de méthodes, un champ, etc. Nous faisons les deux "haut niveau". analyse sémantique, pour déterminer la hiérarchie des types du programme et "niveau de la méthode" analyse sémantique, pour déterminer le type de chaque expression dans chaque méthode. " Niveau supérieur " L'analyse sémantique est assez rapide, et toute analyse de méthode individuelle est assez rapide, mais néanmoins, il est difficile de faire une analyse sémantique complète entre les frappes.

Nous devons évidemment effectuer une analyse sémantique complète pour intellisense, mais nous pouvons nous permettre de déterminer quelle méthode vous êtes en train de taper et de n’analyser que l’analyse sémantique du niveau supérieur et de cette méthode.

Mais la colorisation doit s’appliquer à l’ensemble du fichier; vous ne pouvez pas simplement colorier la méthode dans laquelle se trouve le curseur actuellement. Par conséquent, la colorisation doit être incroyablement rapide, nous avons donc historiquement coloré principalement sur la base d'informations lexicales.

Parfois, nous pouvons trouver des informations spéciales telles que "cette chose est-elle probablement un type?" pour lui donner une couleur différente. Mais déterminer quand une entité donnée est, par exemple, un groupe de méthodes par rapport à, par exemple, un champ de type délégué, nécessite un niveau assez riche d'analyse sémantique, un niveau que nous n'exécutons pas à chaque frappe.

Maintenant, il y a des choses que nous pouvons faire ici. Nous pourrions être plus intelligents pour comprendre les éditions du flux de jetons et ne refaire que des analyses grammaticales et sémantiques sur la partie modifiée de l'arbre. Nous faisons actuellement des recherches dans ce domaine, mais il ne s'agit que de recherches; il se peut qu’il ne soit jamais réellement intégré au produit.

Answer 2

Je pense que le plug-in ReSharper fournit une mise en évidence de la syntaxe améliorée, comme vous le dites. Il se peut également que d’autres plugins fournissent la même chose (à moindre coût), simplement celle que j’utilise. Je conviens que la coloration syntaxique est très utile. ReSharper fait également des choses intéressantes comme un code mort grisé pour le rendre plus évident, mettez en surbrillance la ligne en cours, etc.

-Daniel