Don't add Async suffix when making method async

[vsfeedback]

This issue has been moved from a ticket on Developer Community.

---

When you add the `await` keyword in a method body, Visual Studio helpfully offers to make the method async.

When you apply that change, however, it also changes the name of the method to append the `Async` suffix.

I consider that suffix redundant and don't want to name my methods according to that convention. Is there a setting so that this refactoring feature doesn't change the name of the method? If not, could you please add one?

---

Original Comments

Robert I W Lang on 9/2/2020, 05:31 AM:

Agreed! I want to choose how to name things and not be forced by someone else's naming paradigm.

Mark Seemann on 9/2/2020, 06:11 AM:

Here's an example to illustrate what I mean:

You can see in the preview how the name of the method changes.

Romain DENEAU on 9/2/2020, 09:02 AM:

I agree with you, Mark. No `Async` suffix, or optionally (through the settings or another refactoring or a checkbox). In this case, a refinement could be to check it by default when there is already another method not async (e.g. `FirstOrDefault()` vs `FirstOrDefaultAsync()`).

Nick Craver on 9/2/2020, 02:30 PM:

This has been discussed quite a few times, for example in dotnet/runtime#26908 - the consensus of the framework was that the BCL does use the Async suffix, for reasons there and others. It's also in the official documentation as the convention: https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/async/task-asynchronous-programming-model

> The name of an async method, by convention, ends with an "Async" suffix.

Overall, I wanted to add the voice that this behavior is desirable, and should not be changed. It has a lot of benefits to the reader and is consistent with the framework itself.

Mark Seemann on 9/2/2020, 10:30 PM:

@Nick Craver I didn't intend this to be a discussion for and against that naming convention.

In general, the .NET naming guidelines advise against Hungarian notation, but exceptions exist, the longest-standing of which is that interfaces are prefixed with an I. That convention I do follow, for various reasons.

Visual Studio does have a knob for that naming rule:

My question is whether there's a similar way to tweak the naming rules for asynchronous methods, and if not, if one could be made.

I'm not trying to change how other people name their methods.

Dustin Moris Gorski on 9/2/2020, 11:40 PM:

100% agree with Mark. This is about preference and allowing a user to set it in their IDE just like they can do it for other code conventions too. There should be no discrimination towards async when settings already exist for other code conventions.

Feedback Bot on 9/3/2020, 02:11 AM:

Thank you for taking the time to provide your suggestion.  We will do some preliminary checks to make sure we can proceed further.  We'll provide an update once the issue has been triaged by the product team.

Nick Craver on 9/3/2020, 03:54 AM:

To be clear on my above: an option for this sounds completely reasonable (even if I disagree with the resulting inconsistency), definitely want to ensure that it *is* an option though, and not a baseline change as we've seen in a few of the changes lately. Those have "flipped the bit" so to speak and did not seem to consider why it's that way now with equal weight, resulting in reverting it back and pain for both sides of a preference in the first place.

Mark Seemann on 9/3/2020, 04:18 AM:

@Nick Craver, to be clear as well, an option is all I ask for. I'm even happy if the default setting remains the current behaviour, as long as I have a way to change it. Something to put in `.editorconfig` would be perfect, because I can see how following one rule or the other is contextual.

[CyrusNajmabadi]

Dupe of #26312

[ploeh]

@CyrusNajmabadi This doesn't look like a duplicate. If I understand #26312 correctly, it's only about not renaming the Main method. This issue doesn't mention the Main method at all.

Also, #26312 was closed as fixed in April 2018. The fact that I'm reporting this issue in 2020 indicates that the issue I'm reporting hasn't been fixed.

Please consider reopening this.

[CyrusNajmabadi]

Sorry, wrong issue number. I meant: #20348

[CyrusNajmabadi]

Please consider reopening this.

The issue was taken to a design review and the current behavior is as expected. If, at some point, we get the ability to state that async methods are preferred to not have the 'Async' suffix, we'd update this feature to respect taht.

[avihais]

hi, I also think that this (annoying) suffix hurts code elegancy, we don't suffix any void method with "method" suffix:
public void DoSomethingMethod()
or adding function to any method that returns a value:
public double CalculateNumbersFunction()
also we are not worried that that the function was called but value was not used.
and yet, there is a requirement to add an Async suffix to Any async method , for some reason we do worry for the async method not being awaited (I would except a compiler error by default).
I hope that this suffix convection will be removed as I don't think this is relevant to a modern use of code anymore, anyway, adding Async suffix to a method need to be justified, since many modern code just adding an almost pass-trough code,
I would except that the Async suffix convention would be applied only to public methods and not on every method existing.

[triynko]

Just offering a different opinion here. I think the Async suffix should remain. It's agitating seeing methods named 'Start' that are async methods, but lack the Async suffix.

Option 1:
Start(); // <<-- is Start an async method? Maybe. Maybe not. Who knows. Do I need to call await? Have to look at signature.
await Start(); // << why is someone calling await on non-async method? Expecting async methods to have Async in the name.
StartSync(); // << ridiculous, but would be necessary if a synchronous version was necessary

Option 2:
await StartAsync(); // << clearly an async method that should be awaited; no ambiguity.
Start(); //normal method, as long as we're following convention.

The 'Async' method name suffix is a concise and clear indicator that a method is async and needs to be awaited. This has always been the recommended convention, and it's the convention the .NET common libraries and other libraries have always used. Without it, it's too easy to for developers to invoke methods without calling await, because there's no obvious indication given that a method is async other than in its name. Async in a method name is a clear, concise indicator that the method is async and needs to be awaited. Compiler warnings are generated when async methods aren't awaited, but those are too easy to ignore in large projects with thousands of warnings.

[sravimohan]

Looks like the community is divided whether to the postfix Async or not. So would be great to have an option to disable the postfix Async.

[christattum]

Another vote for making this optional. I think adding the Async suffix makes sense (and is necessary) when there are async and non-async versions of a method. But where there are only async methods, the Async postfix everywhere looks redundant and ugly imho.

[iNetDaniel]

This should be optional for situations like with ASP.NET where an Action is not necessarily referenced directly. Rather the method name is called via Html.RenderAction("MyAction", "MyController"); and the refactor does not automatically update these references.

[CyrusNajmabadi]

Rather the method name is called via

Can those locations use nameof instead?

[iNetDaniel]

Another use case would be for JavaScript that references AJAX endpoints.