"Don't Use Fields in C#! Use Properties Instead" | Code Cop #003

hello everybody I'm Nick and welcome to another episode of Code cop the series where I go on LinkedIn Twitter and blogs and I try to find good advice about writing clean code but in reality that advice is really really bad and I'm trying to convert it into good advice LinkedIn specifically will promote basically anything as long as it gets one like so it's extremely notorious about this type of behavior and in this video I have a LinkedIn post for you which is just nuts as always this is not an attack on the Creator elves but rather on the post itself and the advice that they try to give and that's why they're anonymized always in these videos if you like of content and you want to see more make you subscribe for more training check out my courses on do train.com okay let's take a look at the advice on this video because it is nuts really like I don't know how this is just recommended as advice so the text of the post says the following properties are more versatile than class member variables I used to be all over class member variables those underscore valuable declarations with class scope now I hardly use them properties are more useful they look nicer because there's no underscore Auto implemented properties create an implicit class member anyway we'll explain why that doesn't make any sense later now more than 90% of the time I don't need an explicit class memory varable when I want a Class M varable I still have the option to explicit declare them my code is cleaner and clearer now let's put that into context to understand what the person who wrote this is trying to explain this is the image that they uh accompani the post with so clean code tip prefer properties to class members now right over the get-go this doesn't make any sense because properties are by definition class members so what they mean is prefer properties from Fields that's basically it so what you have over here is a class that's called transaction update use case you implement an interface and then you have a private ey transaction persistor which is being injected from The Constructor I should add over here that this should be read only it's not it's fine and they say that instead of using that what you should use instead is actually a property a private property I I swear I'm not making this up now what I'm going to do real quick just so we have a better idea of what exactly is going on is go back to the ID and I'm going to show you that I have this example over here the exact same thing that's in the post and what they're basically recommending is don't have this private field over here that you inject to the Constructor instead have a property but that property should be private which we will explain why that doesn't make any sense in a second and then that will prevent you from having to deal with the underscore because properties are named using Pascal case and then you don't need a Setter as well because you're going to initialize it in the Constructor now here's a few reasons why this doesn't make any sense first why would you have a property which is a concept that supports encapsulation as a field it doesn't make any sense in fact if I actually go into the code that this thing will be compiled into and I show you how the lowlevel cop will look like as you're going to see a field will be generated over here for that property because the property is basically a getter or a Setter or both depending on what you have and then a backing field to store that data so the outcome is exactly the same but now you also have a getter method which by the way looks like this I'm going to say public I transaction persister and I can say get underscore and this and and as you're going to see this isn't accepted because it is actually clashing with what the compiler will use because if I copy this name and I go to the I viewer you'll see that this name is actually used on the I level to define the name of the method that will be generated as the getter so that's why you can't use it sorry if I'm getting too technical with this but you have to understand why this is a really bad idea now before I move on I'd like to let you know that we just launched a massive six-hour course on D train called from Zero to Hero Test driven development in cop that course will take you from knowing nothing about testing in tdd and get you to a point where you fully understand the concept and you have all the technique and knowledge to apply it on any cop code base it is authored by GE herera who has an excellent YouTube channel Link in the description but he's also someone who I work with personally in my previous company and I can 100% V for him he really really knows the topic and he actually changed the way I see the topic as well and the way I teach it I believe it's a must know for any developer and the first 500 of you can use discount code td20 and click the link in the description to claim it at checkout these do tend to go very very quickly and I don't renew them late so if you want to buy it then buy it now now back to the video so encapsulation makes sense if you have a protected or a public member but for private it doesn't make any sense because you're already in the class that is supposed to have access to the row data to the actual field so why would you make a private property to access that privately within your class you wouldn't it doesn't make any sense sense it is like you're creating a wrapper class like a private wrapper int class for example over here which is here to wrap a public integer like it it doesn't make any sense at all so let's take a look at the reasoning because they actually gave nine reasons why this is a good idea so reason number one it's pretty pure ugly underscores now the underscore of a private field or a private read only which is what they should be filled is that for a reason this is not random we didn't just add it because we hate developers and Microsoft did not add it because they hate developers in fact previously it used to be M underscore but we've changed over the years to just the underscore and the reason for that is because when you're looking at the method down below the Declaration of the class and let's say you have a public void method over here and that method can also have a string text what that underscore helps me see is that if I I have this transaction persist in this case this tells me this is a class level member which is a field just by seeing the underscore and the way it is named and that is it and by having text for example over here be like this I know for a fact that is a parameter of this method as an argument so just by naming it this way without having to scroll all the way up to see where something is declared I can see everything and I can know everything about this member so you can't say this ugly but it makes sense the alternative of course is don't add it you in your own code if you don't want it you don't need to have the underscore just remove it and as long as you're using this dot to maybe be explicit and don't confuse the class level members and the method arguments then you're you're fine you don't have to use the underscore I like it I prefer it because of the reasons I just explained but you don't have to use it and you don't have to change from a field to a property for this to make sense okay the next reason they give is encapsulation hide in internal State you're already a private member in a class what state are you hiding I do not understand this point at all and also the other thing data validation andure valid data I guess that point is about uh being able to have logic in a getter and return based on something that can be validated but then at this point this is a completely different thing it doesn't really make sense plus you're going to be validating every time you're getting this value because that's now a method not a field so performance will be degraded and you're going to be validating every time do you want to validate every time you get this property probably not you just want to store it as a fi in fact if the type of validation you want is to check whether that is null or not you would do it in the Constructor you wouldn't do it on the getter the next thing is property gets computer transform values would you want to add this type of logic in your application like why don't you do this when the value is composed initially so you can do it once and then be done with it otherwise you're going to have to do it every time and actually to the next Point lazy loading yeah you technically can have lazy loading by doing this but then what exactly are you doing because you're not going to improve performance by lazy loading it because you're not really lazy loading it you're going to load it every time unless you store it in a field which means you're going to have to have an extra field just have it once in the beginning why do you have to have it twice it doesn't make any sense at all also visioning like I really do not understand what visioning means here like please if you understand let me know I I I don't get it what are you going to Vision here Implement visioning in the getter why would you do that that's a completely different construct it's not meant for that then you have debugging and logging again are you going to have a log vocation in the getter so you're going to not only return a value that's computed but you like at this point just make a method and put all the logic in the method itself change notification again different thing this is not supposed to be used for everything I know the person said 90% of the use cases will be covered by doing this I would UE 1% of the use cases fall around this not everything needs a notification on the change and nowadays if you need a notification on the change you're going to use a source generated approach to this or an ilil weaved approach to it with something like 40 a notification change not a manual getter so what also mocking and testing simplifying testing and mocking how is that simplifying it it's the exact same thing but actually worse because now I don't only have to worry about what I'm injecting so in this case worry about what I'm injecting and knowing that this will be mapped to a field but I have to worry about injecting this and then worry about whatever is in the gter as well which might need to be mocked or dealt with this advice in my opinion is absolutely terrible you should not follow it it will lead to a really bad design choices and I'm very confused as to how this came about to be I feel like some people just want to come up with some advice to post something but that ultimately leads to bad advice being promoted and people blindingly following it Without Really questioning it but as always these videos are meant to be part of a discussion so please in the comments down below let me know what you think about this type of advice because you know I could be wrong and you could have something else to add into the conversation so which one would you choose and why would you choose one of the other please leave a comment down below well that's all I had for thank you very much for watching and as always keep coding

Channel: Nick Chapsas

Views: 92,102

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 properties, properties c#, properties, properties instead of fields, fields instead of properties

Id: QdfAOVk77v0

Length: 10min 27sec (627 seconds)

Published: Mon Oct 09 2023