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

Good one 🤣

I remember a series of otherwise decent C# tutorials on RU-vid that insisted on calling fields "attributes". Yeah, that's totally not going to get confusing later...

😂😂

"class" + "member variables" I would consider to be redundant (it's like saying "general consensus"), but I don't have a problem with "member variables" or "fields" to mean the same thing. Indeed, "member variables" balances nicely with "local variables".

Hi! I dont't know what you meant, but what I "understood" from this was something like this: class OuterClass { private int _field; private void SomeMethod() { private class InnerClass { private int _innerfield; } var outerInstance = new OuterClass(); } } and this doesn't make any sense. Could you please provide us some example code? As it sounds interesting.

@@g3ff01 Hi, here is a code sample. If you try this approach for testing with xUnit and ClassData, you'll see a different visualization in VS TestExplorer public class Outer { private int _outerField; private class Inner { public int GetOuterField(Outer outer) => outer._outerField; } }

@@nanvlad thank you

You are violating clean code rules already by declaring a class inside another class.

And under the lens of public properties, I would interpret the "versioning" reason as being able to change the serialization of the data without changing the class API.

It's a point of view, but I believe that these people go around putting up these absurdities to get the title of MVP.

Well its their job getting paid off view so they gotta bait the clicks 😂 i hate tech influencers

can it be an advice from chatgpt?

its called rage bait posting.

they will have a better position to protect their idea if it is a public one. But here in this context, we are talking about the private scope. Imagining when you have to talk to your "higher position" about this. I feel hopeless

That's exactly what I thought. Some of the listed advantages only make sense when you're thinking about choosing public properties over public fields (which is a good idea). Mocking for example.

Noob question, but when is it appropriate to use a public field? I find myself only using public properties or private fields, I don't know when I should be using a public field

@slowjocrow6451 For data struct members, one often doesn't want even the minuscule indirection of a property when doing high performance data processing.

@@slowjocrow6451idiomatic c# doesn’t use public fields, only public properties. Edit: riversj makes a good point,but depending on your domain you might never be in that niche scenario

I bet they use the 9 reasons from chat gpt

It actually sounds like ChatGPT. No way a human unironically wrote "9. Mocking and Testing: Simplify testing and mocking." as an argument for properties

f... each comment makes it sound more and more like chatgpt

But don't worry, they're going to write a followup article about how bad chatgpt because of the feedback it's recieved....which is also biased and bullshit hahahah

From my experience with ChatGPT, it would be smarter than those stupid ideas and arguments against fields.

@@AlFasGD I agree, but I think they asked it to generate an article arguing FOR it..cus it will do that haha

​@@AlFasGDit is smart, when you're smart. Sometimes you can make it write something stupid, sometimes it does so by itself, and you need to be smart enough to discard it.

More and more, they might actually be so.

I think this is the answer. I had this conversation more or less a month ago with friends from work. I don't see a need for the underscore but I don't dislike it either. It's visual preference.

How does that improve readability at all? I dont get it...

​@@CZProtton Because then you start with an auto property, single line of code? Only expanding it if and when you need more than just a property with a hidden backing variable

Without an underscore, a camelCase variable will resemble an argument. To differentiate them, you should add "this." on the field. But adding "this." is not enforced by the compiler, but the underscore is (of course, since it's part of the variable name). Ergo, the underscore is better for private fields.

IDEs are powerful now for sure, but we often read code not in IDE, e.g. in a web interface during PR review. Or maybe you want to access some private fields, start typing with _ and LSP will show you the list of them so you don't need to remember the exact name. This makes life a bit easier. But m_* convention is ugly though :)

I got fooled by your avatar! I really thought I had a fly on my screen.🤣🤣🤣

@@alfflasymphonyx Me too. You got me.

Purely feedback on your points to play the other side of the debate. 1. A (if not the) major reason devs expand accessibility is because they find their code is coupled and they want to break the Law of Demeter instead of following best practices. 2. This can't be more subjective. "The Industry" vastly agrees that _thisStyle is more understandable for what it represents. 3. Sometimes devs forget to remove the "set;". Also, "readonly" explicitly says what is happening. A property with only a getter has to be understood. Though as of C#9, you can use "get; init;" which also becomes more explicit. This doesn't change the rest of the points though. 4. Same as #2. We would certainly hope we know PascalCase means it is a class member and not within the function scope. But most of the industry would see PascalCase as a property that might change state. 5. An empty accessor method may not measurably affect performance, but the assertion with some of the "benefits" of the OP is that the accessor method would be abused. 6. I cringe whenever somebody changes their Software Engineering principles to suit a random tool. 7. Nobody can argue with Company Standards. They're up to you and your architects. But this would not match "code style consistency" with the rest of the industry. As for { get; init; } (Which is not part of this OP), that is mainly for records; AKA Structs, Models, DTO's, POCOs. This video and all of the replies so far are talking about interfaces as class members. So those are talking about Services, not Models, and it is irrelevant.

​@@JinnFletch You are absolutely right, both semantically and technically. But I was not talking about "your fancy nanoservice SOLID YAGNI KISS etc code", I was talking about "everyone else's gigaservice WTF LOL WUT code". And in large classes readability matters. As well as debugging. Like you can put a breakpoint on a setter, find all references of a setter or getter. I personally dislike that underscore-snake-camel naming, still I use it to be consistent with the rest of industry which uses it for private members only, no one exposes this naming. So why be consistent? And of course there is just no such thing as "The industry". I'd rather call it crab bucket.

I like underscores in private field names. It highlights them as what they are, and I immediately know how to handle them.

I always interpreted it as supposed to be ugly so that you ignore it when skimming the code. As you usually look for properties or public members when skimming code.

@@dantecavallin8229 this is exactly how it was designed in python, where everything is public, underscore just suggest not to use it

@@dantecavallin8229 True. They look different and like something you wouldn't want to expose to others (consumers of your library). And I like marking them as such... or "uglify" them.

@@brianviktor8212 I do the underscore only for backing fields if I need them for a property.

I agree that underscores should be used to denote private backing fields that should not be accessed directly (ie backing fields for source generated change notifiyng properties, that would not work otherwise). To specify that what we're accessing is a class member rather than a local variable, we can still use the 'this.' which is more explicit

Not sure. For auto properties an optimization should work which uses the field directly without get/set method

That's what break on value change can already do. It just shows the person has no clue how to use a debugger

In my opinion, if you are performing complex logic when getting or setting a field, then that should be the job of a well named helper method or extension method. Because in the calling code, merely “getting” a value doesn’t necessarily tell the reader what is happening to that value before it is being delivered to the caller. So if you had a variable called appleNames and your getter logic returns the list as an alphabetical list, then you should have created a private method called GetAppleNamesAscending() paired with a field. That way your code doesn’t look like it is doing magic. Every time you have magic, it takes a few seconds, up to a few hours, to understand what’s going on. Multiply that by hundreds of these little magical code references and you’ll have a mess on your hands.

The case that we don't have any 'public' members - they all private

That's exactly what they refer to, and given the knowledge the person has about the language, they would still fail to understand what they are proposing for.

There's no way they're referring to binary compability considering the rest of the post.

@@Stealthy5am you know this could very well be an idiot munching the same chew gum as all others, and simply reproducing the brief summary of random arguments found online about preferring properties over fields

Except they made the property private which means it's not part of the public API.

Yes, absolutely!

it is really hard to debate with a higher position especially if they give you a StackOverflow link of a highly rank author: are-there-any-reasons-to-use-private-properties-in-c

I Agreed.

Well the alternative is the this. instead. I, on the hand, find that ugly but what ever coding style you like you can use. As long as it's only you on the project or you agree with the rest of the team that this is how you would name things. There is no right or wrong here, but there is a standard way of naming things and you can use it if you like it or use your own if you prefer.

@@CRBarchager You can just as well use standard camelCase and let IntelliSense do the work for you. It tells you whether it's a local variable or field. The main difference is the at a glance, which is the decision people have to make.

Yeah but I dont think one should rely on everyone who will ever read this code to have such an IDE and setup

You should *always* use an underscore prefix for intellisense. At a lower level, it's the standard way for expressing intent.

this is it.

i guess you work alone on a project without pull requests. You also want readable code in code review on a webbrowser in the compare window.

Readability of the PR in the browser was a concern at first, but so far (~10 devs, ~5 years doing this) there were no real issues I think some of the reasons for that are: - class names usually give a good idea of what the context is, eg. UserController, ArticleRepository, ... - fields names usually indicate functionality, eg. customerRepository, orderService, dbContext, ... - parameters names usually indicate data, eg. createCustomerRequest, userName, validUntil, ... - usually, it doesn't matter where an object comes from in a method as long as we can use it (and when it does, the issue tend to be in how it was injected and the lifespan it was given) This just my experience, definitely not a silver bullet but it works for us, colors are consistent even if you use _underscore :)

Same here. Everything that belongs to the class starts with this. If it starts with a lower case, it's a field. If it starts with an upper case it's a property. If it ends with ( then, it's a method. If the call doesn't start with this, then it's static. The fact that this advice starts with saying that it's nice to have no underscores shows this writer could not think outside a convention and may not even know about the StyleCop way.

lol, I was about to point out private fields would not be accessible externally, then read your last line.

But what if the caller is using reflection to access private members? 😛