Thursday, 07 September 2017
Richard Blewett
3 minute read
There is a common pattern that is used in .NET APIs where anything that returns a Task
has the suffix Async
.
Task<Result> GetResultAsync();
However, in reality, this is just another form of Hungarian Notation.
"But Microsoft do it in the BCL", you may say. And of course you are right. But lets be clear - they had to as they already had synchronous versions of the APIs from previous versions of .NET.
WebResponse GetResponse();
Task<WebResponse> GetResponseAsync();
So the Async
suffix really came from expediency rather than a proposed standard pattern. In fact, where the API already supported the Event Async Pattern (EAP), there already existed a version of the API with an Async
suffix so they had to use TaskAsync
to disambiguate.
Task<byte[]> DownloadDataTaskAsync();
If you have to support both a sync and async version of an API, then maybe still use it - or rather, to encourage async interaction suffix the synchronous version with a Sync
suffix as in NodeJS APIs.
But most APIs should be either inherently sync or async and in that case leave off the suffix and just return the appropriate type.
Last updated: Monday, 12 June 2023
Director
He/him
Richard is a Director at Rock Solid Knowledge.
We're proud to be a Certified B Corporation, meeting the highest standards of social and environmental impact.
+44 333 939 8119