Don't add Async suffix when making method async

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 https://github.com/dotnet/runtime/issues/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.

[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.

[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.