Runtime: "Async" suffix on awaitable methods, anno 2019

[IanKemp]

Yup, it's that time of the year folks: the time when we inquire "is it still Microsoft-recommended practice to place an Async suffix on all methods that return a Task or Task<T>?"

I would assume that the canonical answer is "yes", given this page that states unequivocally:

You should add "Async" as the suffix of every async method name you write.

However, that page was last updated in 2016, and it ain't 2016 anymore, so I'd like to know if this guideline has changed at all, or remains in place.

To clarify, I am not looking for a debate on this topic - I am looking for an official answer, from a Microsoft representative, on whether this guidance is current or not.

Previously: https://github.com/dotnet/corefx/issues/31275 but there wasn't an official position stated there, hence why I'm asking again.

[anarsen]

:thumbsup: this comment if (still) you agree with the proposed guideline in dotnet/runtime#26908, i.e. only use Async suffix if you provide both.

[Miggleness]

I used to be with the don't use async anymore camp, but realize keeping that suffix does made code easier to read for others

[stephentoub]

is it still Microsoft-recommended practice to place an Async suffix on all methods that return a Task or Task?"

Yes.

[jeffrymorris]

FWIW - early alpha releases of the couchbase .net 3.0 sdk went with the "no Async" postfix and we had plenty of feedback indicating it wasn't well liked. We have since added "Async" to all public awaitable methods.

I used to be with the don't use async anymore camp, but realize keeping that suffix does made code easier to read for others

That was the number one reason; by reading the method name you know you must add an await.

[terrajobst]

I was just about to close this issue as well. To provide a bit more rationale:

When deciding on guidelines, consistency trumps virtually everything else. Developers don't just use one component of .NET, they use a ton of .NET components. So even if an entire component is exclusively async, staying consistent with other components that offer both async and sync APIs helps. It also helps in code reviews because calling a method that is suffixed with Async but is not awaited is almost always a bug.

This isn't a guideline that we'll ever change because there is just way too much existing prior art.

[IanKemp]

Thanks guys!