"The readonly Keyword Is Useless!" | Code Cop #012

hello everybody I'm Nick and welcome to another episode of Code cop the series where we go over questionable advice given on LinkedIn Twitter or blogs and we try to turn it into good advice LinkedIn specifically is notorious for the algorithm promoting really really bad advice because it takes very little likes to get promoted to other people's Network so in this video I have a very interesting piece of advice by someone I personally follow because they tend to provide really really good advice so the reason why I'm making this is because even though it's something I've talked about in the past I want people to watch this video and understand that just because the general advice given is good it doesn't mean that this specific thing is good and it's not necessarily terrible like other things we've seen in code cup but it is pretty bad in my opinion because there is not enough context and usually that's the biggest Pitfall of post on LinkedIn now as always everything is anonymized this is not about the person this is about the advice if you like of content and you want to see more make sure you subscribe for more training check out our courses on do train.com okay so let's take a look at the advice itself and usually all of them have a photo associated with it and in this case the photo is this primary Constructors less boilerplate those of you who have been following the channel for a long time are probably tired of me talking about this topic but as long as people especially really good people give similar advice I have to explain why I don't agree with it now I should make something very clear before I go into this specific example I love primary Constructors in general I just don't think the advice given on this specific context is good and I think you should stay away until they eventually fix it in net 9 or Net 10 which is more like C 13 or C 14 actually so what's the advice with a new introduced primary Constructor you can remove a lot of boiler plate code from your injected services from dependency injection container so in Net 7 you have this private readon I dependent field that's being injected through the Constructor and then it's being used in the do method and now with net 8 and C 13 you can merge all that in this primary Constructor now because this is used into a method in this specific example the outcome behind this IM will be the same or will still have a field captured even though it's a Constructor parameter because that will need to then be used into a method so as long as a method in your code is using it a field will be generated we can see that very easily actually if I go on this very specific example and I go to the lowlevel C shop and if I expand it you will see we have the ependent field there's a bit of a difference which I think is a major difference but fundamentally you still have a field you still have Constructor injection assignment and then usage in the do method now if the do method was not using that injected parameter so if I just comment it out and I rebuild then this Constructor parameter will just be disposed and not used so there is no field captured you have to understand that in primary Constructors the ability to capture a parameter in a field is only there if you later use that parameter into a method or into a property or into something in your class now before I move on I'd like to let you know that we just launched a brand new course on dome train called Deep dive into modular monoliths and it's a direct sequel from the getting started delivered a few weeks ago by adalis or Steve Smith Steve did an amazing job with that first course and you loved it so we had to get out the Deep dive one as fast as possible just to see how the whole application is completing and being ready to go to production with more features and more modules to have a complete modular monolith which in case you don't know I think it's the goldie log zone between microservices and old bad monoliths it's where most people and by most I mean almost everyone should start before they feel like they have to go anywhere else maybe microservices or maybe even further both the Deep dive and the getting started should be taken by every net developer working in modern. net there's so many best practice you're going to learn there and to celebrate the launch of the Deep dive you can use code modular 20 at checkout or use a link in the description to claim 20% off that course and you can also add the getting started course in your basket for a massive discount if you don't have that already and on top of that we also have a from Zero to Hero modular monol bundle now which allows you to combine both courses with a 20% discount okay now back to the video so the problem isn't really with the general advice of this and I would agree with it except for one thing this readon keyword we don't have a way with primary Constructors to specify that the parameter being injected is read only what does that mean well that means that if I go here and this is read only and I say that dependent equals null for example well I can't do that because the compiler doesn't allow me this field is read only however if I was to use even the suggested refactoring here to turn it into a primary Constructor well okay the compiler now allows and it very nicely refactors this but what if I just say now dependent equals null now I have the ability to do that because my code allows it because that read only keyword cannot be used here and you can say that this is nice because now I don't have to carry that read only word around but the truth is well why that was functionality you had in there and it's there for a reason you saying that you can have this parameter over here turn into a primary Constructor and technically be the same thing well it isn't because you just lost a crucial part of your application or your class the ability to have this as read only if it doesn't matter to you I dare you go to every single one of your applications that have a private read only field injection through the Constructor and just remove that readon parameter and see how it goes in your code review but if you have a proper code review framework in place this will be rejected because there is no reason for your class the class itself to be able to mutate what is being injected through dependency injection there's a reason why that's being injected it is to be used now you can say well you can see the class just don't set it to anything that's not enough of a good excuse for me because with the same logic well you know don't use a property don't do something like this so public in ag for example and have a getter and a Setter that can have also logic in them just have a public field right because you know your application is being used by you and you can only set the age and the setter and get the age through the field so why don't we just have Fields everywhere well having safeguards in place makes it easier for everyone to work with the code both us and consumers and even if you're working in a given class having that safeguard that ability to prevent someone from doing something unintended is there for a reason now I always like to provide the context because some people also write some text alongside the LinkedIn post so in this case the post was primary Constructor cop 12 and net9 with the new addition of from Constructor in the upcoming net 8 and cop 12 release which by now it's released so this is a bit outdated this post however was published two weeks ago so I'm assuming this was a canned or reused piece of advice which by the way is very common for people in LinkedIn to do there's some people who just recycle the same picture over and over again every week and it works because all of them are getting hundreds of reactions so it's amazing it's great and the question is what do you think about this new way and thankfully the comments on this post actually address this disparity and that's great people like John for example jump in the comments and say you can Define values as read only that can be dangerous 100% agree find from Constructors of entities where you define properties I 100% agree with Johnny here not so much for s is where you're injecting dependencies I couldn't agree more John if you're watching the videos amazing advice also doesn't result with mediator handlers bummer I didn't know that this was a reason because I haven't obviously used mediator handlers with this feature but if it does well that's interesting then because reflection seems to be working differently behind the scenes as well which I'm guessing I'm going to have to do a deep dive and understand what other problems this feature can have now many people ask is there a way to use a primary Constructor but still have a read only field and there is and it's not great but I'm going to show you so I can convert this into a primary Constructor and then what I can say is private read only I dependent of dependent equals dependent and then I am using the underscore dependent field over here this has a compiler warning and basically a graying out saying just remove this dude and use the parameter directly into a method so we don't really want to do that but if we were this is exactly what solves the problem if I compile this this code and I go into the I viewer you will see that now we still have that fi but is now read only and is setting the value correctly over here so this approach gives us exactly the same code as what we had before it doesn't look great and IDs are like what exactly you trying to do here but it is still shorter than what we had before so you make your own choices here and I do want to know from you in the comments what do you think about this do you care about the read only not being available here would you like to have it if yes how use read only maybe use the V keyword like cotlin or what is your opinion about all this leave a comment down below and please let me know well that's all I had for you for this video thank you very much for watching and as always keep coding

Channel: Nick Chapsas

Views: 35,306

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, code cop, code cop nick chapsas, code cop nick, code cop primary constructors, code cop readonly

Id: Gvz4eSYJFWk

Length: 9min 41sec (581 seconds)

Published: Mon Feb 26 2024