Should You Use The Async Suffix in C#?

hello everybody I'm Nick in this video I want to talk about using the async suffix in your cop methods when the return type is a task that is supposed to be awaited now I'm sure you see this all the time in C code in general where you have do something async and you're supposed to await that method but why do we put that async method exactly how did it come to be sort of the norm and why it is not used in some places now I do understand this is very very opinionated and the reason why I make this video is so everyone can express their opinion and the thoughts about why they use it or not use it or how they use it in the comments down below so if you do use it or you don't use it please leave a comment down below letting us know why you do so as part of this video I will also be giving my opinion all the matter as well if you like of content and you want to see more make you subscribe more training check out my courses on doet tr.com okay so the async suffix what am I referring to let's take a look at some code I have over here from a previous video talking about radi caching now if you go to the weather folder you're going to find this ieather service and this ieather service is supposed to be a service that allows you to get the weather for a given city in the world and the way I named it in that video is get weather for City async now why did I say async here well that's kind of the norm and it's more of a legacy thing that we kind of carried over because you have to understand where it comes from back in the day C only had synchronous methods you would return a void if it was a task in this case unless the task was supposed to be just run in the background or you would return the type itself not a task of the type itself when we did eventually get away a sync in C 5 however we got in a situation where you have your synchronous methods that block the thread and weight over there and then you have your async methods that are non-blocking they are concurrent and just so they can coexist with other methods they had to be differentiated somehow and the reason why we needed to do that is because imagine that we did not have the async method suffix but we did have an extra method that doesn't return here a task of that type but the type itself if we did that you're going to get a compilation error saying that member with name signature is already declared so you couldn't have both a synchronous and an asynchronous method just differentiated by the return type makes sense this means that we got into a point where you had synchronous methods and asynchronous methods and you couldn't just delete the synchronous methods because well they're here to be backwards compatible as well yes you're supposed to be using the new methods when you can but when you don't you don't want to break anyone a prime example of how this worked the time is the web client class which you can imagine sort of as the previous HTTP client class so in web client which still exists by the way we can take a look over here and see that we have a bunch of methods for example upload data which is a synchronous method and upload data async the only difference if we go to definition is the return return type and the name so you have a bite array for upload data and no async suffix and if I go to upload data async is a task version same with download data download data async download string download string Ayn as you're going to see it's going to be the same sort of idea and concept what's also very funny to me is that if you do a bit of a research here you're going to see that we also had the task async naming convention so you would have as you can see here download data download data async download data task async the reason for that just so you don't get confused is that when you try to add a tap method which tap refers to the task based as synchronous pattern then if you already had something with an asyn suff you supposed to be using using name task async super confusing we don't really do this or see this anymore but if you happen to say it just so you know that's why we had it now before I move on I'd like to let you know we just launched a brand new course on D train called from Zero to Hero n framework in that course our new author hannes laet will take you into an eight-hour Journey learning everything there is to learn about n framework and this course is actually two courses into one we did think of releasing them as two separate courses but it makes more sense for your experience to be one massive one hannes is an excellent teacher who has been teaching n framework for years he does conference talks workshops he's just amazing and I know him personally he was one of my very first handpicked authors for D train and he knocked it out of the park with this one there is no better anti framework results out there right now all up to dat with everything you need to know all the way up to net 8 now as always to celebrate the launch i' like to offer the first 500 of you a 20% discount code so use the link in the description and don't wait for Black Friday because this course will be excluded on Black Friday so 20% will be the max you can get all right enough with that now back to the video so we kind of established with this pattern that this is an old thing where when you have both of them in the same space it makes sense to have a Asing suffix but moving forward more and more apis in cop stopped having the sync version everything was just async by default so why would they still be suffixed with an async suffix well by that point because of how many years we had it it was sort of expected that you would do so to indicate to the color that this is a thing that returns a task because maybe it's not immediately obvious and especially warnings back in the day by the compiler were not as good so you would say async and you would have something that is awaitable so you would use the await keyword because we also have tasks that just run in the background so if that's the case and we're supposed to be using async as a suffix just by convention and as a pattern why things like controller methods don't have an async suffix because if you go to any sample or Microsoft code or anywhere you will not see an async suffix in controllers I'm going to go into some code I have here from my workshop that I'm running and again if you're interested in attending one of those Workshops the link to see where I'm running them is in the description and if I go to this controller over here you're going to see create even though it's an async task then get even though it is an async task get all update whatever but the methods themselves in the customer service I'm injecting do have async as a saix why is that well that's because controller methods are supposed to be called by the the framework not by a human so you don't need to indicate to anybody that this is supposed to be awaitable that's why you will never see controllers or in general things that are supposed to be called by the framework have an async suffix what's very interesting is if you go to documentation from back in the day we can actually search for async or actually for suffix and you will see some guidelines allowing you to know how you should name and how you should expect the naming to function and you can see that in Microsoft official guidance from Visual Studio 22 12 which is a long time ago I know but it was the official guidance you can see that they say the name of an async method by convention ends with an async suffix so you're supposed to sort of have it there and expect it to be there so what do I recommend what am I doing in my cop code well I'm following this simple approach usually to this day I am still using the async suffix if I have an eye customer service or something that is supposed to be a task of tea that is supposed to be awaitable then I will have the name of the thing and then async as a suffix and that's not necessarily because I want to have it here but because it's sort of expected that this point to have it there however I will never use it in something that is supposed to be primarily called by the framework controllers you won't see it mediator handlers you won't see it because that is not supposed to be called by an individual that is writing the code but rather the framework itself that is autowired up and this also includes things like unit test of course if I'm writing a unit test or a test of some capacity I will not have the acing suffix on the test method itself because it will be called by the testing framework and now this is where I want to know more about how you do this do you agree with my Approach do you disagree do you just not use it at all which is something I've seen quite a bit actually do leave a comment down below and let me know I'm really really curious and please have a healthy discussion because this is a heavily opinionated topic and I want to have as many opinions as possible so I can actually shape my opinion based on something that does make sense well that's all video thank you very much for watching and as always keep coding

Channel: Nick Chapsas

Views: 61,180

Keywords: Elfocrash, elfo, coding, .netcore, dot net, core, C#, how to code, tutorial, development, software engineering, microsoft, microsoft mvp, .net core, nick chapsas, chapsas, dotnet, .net, c#, async suffix, async suffix c#, async suffix .net, await async .net, await async c#, Should You Use The Async Suffix in C#?

Id: C0sqinpIUBI

Length: 8min 3sec (483 seconds)

Published: Thu Nov 16 2023