"Stop Using Properties in C#, Just Use Fields" | Code Cop
Vložit
- čas přidán 3. 03. 2024
- Use code MODULAR20 and get 20% off the brand new "Deep Dive into Modular Monoliths" course on Dometrain: dometrain.com/course/deep-div...
Become a Patreon and get special perks: / nickchapsas
Hello everybody, I'm Nick, and in this episode of Code Cop we'll take a look at some really insane advice that says that you shouldn't use properties in your C# classes if you want immutability, but instead use readonly fields.
Workshops: bit.ly/nickworkshops
Don't forget to comment, like and subscribe :)
Social Media:
Follow me on GitHub: bit.ly/ChapsasGitHub
Follow me on Twitter: bit.ly/ChapsasTwitter
Connect on LinkedIn: bit.ly/ChapsasLinkedIn
Keep coding merch: keepcoding.shop
#csharp #dotnet
The problem with social media these days is that negative feedback isn't visible anymore to all.
There are so many reasons why immutability can be good and that LinkedIn post managed to identify none of them.
I start to think people are exploiting this channel by sharing such ridiculous statements on LinkedIn... can't be other way.
I didn't know about the with keyword. But it's great.
I am very tempted to comment on these posts: "Congratulations! Your post has been featured in Nick's Code Cop series!"
The fact the explanation makes more sense during showing the post makes it clear that it was way too hard to explain something so obvious to someone that doesnt understand how to write c#. At the end I just feel like you try to make simple something that is already way too simple. You're a hero for trying to save people who believed that post ;(
Yes, not using properties makes using EF harder but also WPF. It may not be the framework of the day but some of us still like and use it.
I love these series so much. You are so on point on everything.
Imagine someone reading this and then applying it to a game in Unity or MonoGame; every time something gets hit and loses HP, you have to replace the entire object rather than just updating the HP value.
I always forget about Records in C#. I keep thinking they're useful every time I see them used, but I always forget about them when writing my own code.
It’s extremely helpful to put a breakpoint in the setter to find exactly where some value is getting set. Especially with rambling legacy code.
Hey Nick!
Being able to blend functional and OOP concepts in an optimal way is the mark of a good C# developer.
I really agree with most things you said, especially in related to those posted texts.
Nick's reactions in this video are brilliant and just say it all.
I agree that every class do not have to be immutable.
Yeah it's context that matters. Such advice usually refers to when ppl make everything an auto property just by sheer momentum. But yeah, instead on focusing on fields vs properties, they then talk about immutability because it's the hip thing to talk about and everything has to be about immutability and purity
On topic of immutable-everything, could you perhaps talk a bit about where it makes sense to use functional approaches? Maybe even interop with F#?
There is one case for the field approach. If you have large structs like Matrix or Quaternion you can pass it by reference `Method(in lssrgeStructToPass)` so to avoid creation of new struct on each method call. You cannot do that if this is a property.
The reason why I'd avoid auto properties specifically (if I could, curse EF with its strict usage of only properties and built in json serializer for the same by default) is because then it becomes a superfluous function call in both directions. I was once asked why I pull an array's length out any time before I run a loop and it is for this very reason, every time the comparison in your loop is made, you no longer only have a comparison, but you then also have a function call of which I am unsure of if it gets optimized out.