Roslyn: Ability to classify fields, locals and parameters differently

[KirillOsenkov]

Add ability to classify fields, locals and parameters differently than just identifiers, so they can have colors other than black. Teams resort to prefixes such as _ or prefixing fields with this. just to visually separate fields from locals. The IDE can easily help with that.

[HaloFour]

I'd love to see that opened up to all of the following:

1. local
2. parameter
3. constant
4. static field
5. instance field
6. static property
7. instance property
8. static method
9. instance method

I'm probably forgetting a few. Maybe also separate mutable fields from initonly fields?

Not sure if this is the place but I'd like to see more font styles supported too. _Italics_, underline and strike-thru for instance.

[dpoeschl]

/cc: @matthejo, who was also asking for this recently.

[DustinCampbell]

I'm very interested in knowing what sort of member breakdown people would be interested in specifying separate colors for. Adding this feature has never been a big deal and there wouldn't be a significant performance hit -- after all, we already bind every identifier in order to decide whether it should be "black". :smile:

I think that highlighting difference between static and instance is a good. We've thought through several others over the years, so I have some questions:

• What about readonly for fields? @HaloFour mentioned that. Is it meaningful? We could also extrapolate that to getter-only properties as well.
• What about events? If we classify other members, events (instance and static?) should be classified as well.
• Is the difference between constants and local constants meaningful? Actually, are constants meaningful at all, or should they just be fields and locals?
• What about unbound identifiers? Today, we should leave them as plain text and rely on squiggles to draw your attention but other editors color them clearly (e.g. bring red).
• In C# Script, we'll have script variables and top-level members. Should those be different?
• How about operator overloads? It seems like it could be useful to see when _my_ + is used over the regular + operator.

As far as other font styles like italics go, they'll require more significant changes in Visual Studio to the Fonts and Colors options page. Otherwise, you won't be able to change them. That work's not impossible but it'd take a fair amount of coordination to get on the right team's schedule.

That brings up another concern that I have, which is being careful not to have an over-explosion of options here. Having too many options is increasingly difficult to manage in the current Fonts and Colors page. Yes, of course that should be revisited and redesigned, but it'd be great if we could add some value without going back to the drawing board.

[ufcpp]

I'm worried that some font styles like italic do not fit non-alphanumeric characters. In fact, CJK characters does not have italic style. If you apply italic style to CJK characters, it happens nothing at all or they are displayed as ugly skewed font.

[DustinCampbell]

@ufcpp, I don't think we're talking about changing any defaults to italic or other font styles. We would probably leave the default color schemes the same but enable support for other style options.

[HaloFour]

IntelliJ already has different color and font styles for many of the options presented above. For example, static fields are in italics. Final fields are in bold-face. I'd say that as long as these additions don't pose a performance issue in rendering that there should be as many as possible. IntelliJ styles also seem additive, for example an unused static final field is bold and italicized, but also light gray vs. the normal darker purple, which is really nice.

I'm torn about not changing the default. Changing it would definitely be controversial and nobody anywhere would be able to agree on those changes, but it feels like it should be a quick option to enable. Maybe for someone upgrading from a previous version of Visual Studio it would retain the existing style but new installs would be asked if they want the new style?

[HaloFour]

IntelliJ styles also seem additive, for example an unused static final field is bold and italicized, but also light gray vs. the normal darker purple, which is really nice.

This is exactly what IntelliJ does. The different types of identifiers form a type of inheritance tree. Root nodes specify their font style and derived identifiers can override individual attributes. A "static field" is in Italics with a foreground color of purple, and "constant (static final field)" inherits from "static field" and also sets bold-face. This is nice in that you can tweak individual aspects of certain identifiers or keywords without having to redefine them from scratch. IntelliJ could've taken it further than it has, though. For example, "static field" and "instance field" are both root nodes instead of deriving from a common "field" node, which seems weird.

I don't know if this is something that Visual Studio could add. Assuming that the effective style per type is calculated and cached I couldn't imagine it having a negative impact on performance anymore than expanding the identifier types would. I would like to see the further addition of more styles. Beyond what Visual Studio already provides IntelliJ also offers Italics, error stripes (the little line in the scrollbar), underlined, bold underlined, dotted underlined, underwaved and bordered.

[clairernovotny]

Bump? Any chance of getting this on the schedule?

[soeron]

+1 for that feature

[laicasaane]

I'm currently using Codinion to highlight methods, parameters, static, const and also constructors (constructor of struct has the same colour as struct's name, which differs from the colour of class). However, I really hope to see the day these features be default to VS without the need of extensions.

[tezine]

+1 for this feature!

[CyrusNajmabadi]

I'm willing to take this feature on. It probably should tie into David's work for 'Symbol Specifications'. That way you can define your own symbol specification and give it a color as well. We'd have similar logic to 'naming style' where the first matching style would be the one we would pick.

Seems like 'Colors' is something we could add to the 'Code Style' folder in Tools|Options. If i have some time, i can try doing this. My big concern is availability of things like an actual ColorPicker control that we could use.

[OlivChu]

@CyrusNajmabadi That's great! Hope to see it soon.

[diryboy]

It's nice to have so many options, but I find it too distractive to have too many colors and styles in code. And the line between useful and distractive would be different for everyone. Once people find a lot of options are able to change, they either spend a lot of time tweaking themselves, or find a place to download something shared, maybe then do a little changes and move on.

Maybe we need to put several examples for people to choose or start from. Maybe we need to put an example code snippet that shows all possible color elements. Then maybe switch the preset schemes from a dropdown list and quickly see what it looks like. Then maybe click on one element and quickly change its color and able to click a button save as their own settings, maybe provide a name if they want.

That sounds a lot, but just some ideas.

[alrz]

and captures :)

[MgSam]

I like the optional color scheme R# uses. It's a good balance between adding useful information but not an overwhelming amount.

[lachbaer]

Please add support for branch/jump/exit statements (see #18810)

• return, yield
• exception exits - throw
• loop break, continue
• "wild jumps" - goto
• switch-breaks (in contrast to loop breaks they belong to every switch construct)

[CyrusNajmabadi]

At this point we would just allow people to specify how they want every keyword to look.

[lachbaer]

@CyrusNajmabadi

Will it be possible to distinguish semantically? Especially I mean exceptional loop-breaks vs. ordinary switch-breaks.

[CyrusNajmabadi]

I doubt we would expose anything to distinguish those cases. If you need that level of control, i recommend just writing your own classifier.

Right now you can just put your caret on the keyword and have the right things light up. That's likely the max level of investment we'd put in as this would just be taking away from other work we could do.

[mkrueger]

1+1 on that - we really could need that for visual studio for mac. Since we supported more fine grained classification options. In xamarin studio we had

“User Field(Declaration)“,
“User Field(Usage)“,
“User Property(Declaration)“,
“User Property(Usage)“,
“User Event(Declaration)“,
“User Event(Usage)“,
“User Method(Declaration)“,
“User Method(Usage)“,
“User Parameter(Declaration)“,
“User Parameter(Usage)“,
“User Variable(Declaration)“,
“User Variable(Usage)”

On top of the various types. However if it makes sense to color declarations & usages differently is hard to answer.

[KirillOsenkov]

Potentially related: https://github.com/dotnet/roslyn/issues/25924

[JoeRobich]

implemented in https://github.com/dotnet/roslyn/pull/31231