Roslyn: Support "negating" style in naming conventions for EditorConfig

[kuhlenh]

Today, I can write a naming convention that says:

Enforce names to start with "xyz" prefix / end with "abc" suffix / etc.

However, sometimes I want to prohibit the use of a prefix/suffix/etc. to have a rule that is more like:

Prevent field names from starting with "m_" or "_"

[Pilchie]

How is this different than not specifying a prefix or word separator and picking a capitilization story?

[kuhlenh]

After talking with @Pilchie, this is "by design". A team should be able to configure the rule as

Field names must be lowercase

and if the word separator is empty, then any occurrence of an underscore will trigger a violation. This is being tracked here now: https://github.com/dotnet/roslyn/issues/18409

[sharwell]

I was just looking at how the naming styles configuration might relate to #18467, and realized that while it's possible to enforce that a particular method ends in Async, it's not possible to enforce that a method does not end with this suffix. Given that there is also no way to create a naming specification based on the return value, it's probably not the only limiting factor for creating an "Avoid Async suffix" convention, but it still seemed like the lack of negation would prove to be one limiting factor here.

[xperiandri]

Yep, this must be implemented! Just a single negating field would be nice.

[xperiandri]

So when? Critical feature!

[damiarnold]

I was just looking for the exact same thing mentioned by @sharwell when I stumbled upon this thread.... the ability to specify that non-async methods do not end in "Async".
Here's hoping this feature gets included soon!

[xperiandri]

Moreover if your async method is an MVC controller method it must not end with Async!
How to handle this case too?

[jnm2]

Non-root .editorconfig in the controllers folder which disables the rule?

[xperiandri]

@jnm2, great idea.

[xperiandri]

However if controller have private async utility method then it must have Async suffix.
So the rule is more complicated

[jnm2]

At the end of the day, .editorconfig can't know about framework-specific rules like those that apply to MVC controller methods. You might have to err on the loose side with the .editorconfig at some stage.

What would be cool is if it was possible for an MVC analyzer to suppress .editorconfig examination of controller methods, applying its own diagnostics.

[hajekj]

Or maybe add some sort of exception if it is inherited from some class like Microsoft.AspNetCore.Mvc.Controller?

[arfmach]

I was just looking for the exact same thing mentioned by @sharwell when I stumbled upon this thread.... the ability to specify that non-async methods do _not_ end in "Async".
Here's hoping this feature gets included soon!

One must not forget that it implies two negating rule types:

1. method name do _not_ end in "Async" (negate required_suffix); and
2. method has _not_ the modifier "async" (negate required_modifiers)

[CyrusNajmabadi]

method has not the modifier "async" (negate required_modifiers)

This is not a naming style. This is a personal repo choice about it async mtehods are allowed or not. I don't think the Roslyn IDE should have any styles that restrict that sort of thing. If you want to prevent async-methods in your codebase, just write your own analyzers that looks for this and errors if it finds it.

[arfmach]

@CyrusNajmabadi : no, I think you didn't get the point. It is not about forbidding async methods. As stated above, you can place a rule that says that async methods must have the "Async" suffix; for that, you must use the required_modifiers = async rule and required_suffix = Async rule. I just said that, to declare the opposite rule (non-async methods must not have the suffix Async), the subsystem must have the negating rules of both specifiers, not only required_suffix.

[CyrusNajmabadi]

I don't understand this part then:

method has not the modifier "async"

There shouldn't be any naming that is dependent on the 'async' modifier. The 'async' modifier affects the internal parsing of a method. It has no impact on its external shape, and should not be part of hte naming.

For example, if i have this real method:

c# public Task<int> GetCountAsync() { // some work return ComputeCountAsync(); }

This method should end with 'Async' even though it has no 'async' modifier, and even though it does not use 'await' inside of it.

[CyrusNajmabadi]

I just said that, to declare the opposite rule (non-async methods must not have the suffix Async)

Methods are asynchronous or not depending on the return type of the method not depending on the modifiers of a method. Negating modifiers doesn't make sense in this case.

[IanKemp]

Would be nice to have this to cover scenarios like the following: https://stackoverflow.com/questions/54685182/editorconfig-rules-for-differing-naming-of-private-constants-vs-private-fields

[sharwell]

@IanKemp You need to break up the rule for const and readonly. The required_modifiers property is a "match all" constraint. Placing more specific rules first is a standard approach to the naming rules. For example, this repository has a rule which applies to all fields that are _not static_, and we apply the rule by simply defining the rule for static fields first:

https://github.com/dotnet/roslyn/blob/b4a4a984a5d11b079940beb87d9f032ad0250eb3/.editorconfig#L76-L95

In the same file, we also have rules (located above that snippet) for non-private fields and constants.

[rubberduck203]

There’s a lot of talk about async here, but I’d like to propose a much simpler use case for this.

The best I can tell, the naming rules explicitly ignore leading underscores when specifying camel_case, so there’s currently no way to specify that private fields should not have a leading underscore.

If we could negate a prefix, that would provide a solution for #22745

[alexshikov]

What are the chances this feature will move forward?

[VincentH-Net]

This feature would be very useful to modernize conventions in existing codebases. E.g. I am currently involved in moving a large product codebase, that uses some obsolete conventions, to Azure.

E.g.

• No _ prefix for private fields
• No Async suffix for async methods (unless there also is a non-async overload)

Any chance this will happen? Or an alternative way to do this?