Menu
Seems like every C# static analyzer wants to complain when it sees a public field. But why? Surely there are cases where a public (or internal) field is enough, and there is no point in having a property with its get_ and set_ methods? What if I know for sure that I won't be redefining the field or adding to it (side effects are bad, right?) - shouldn't a simple field suffice?
559
Fields can be marked as public, private, protected, internal, protected internal, or private protected. These access modifiers define how users of the type can access the fields. For more information, see Access Modifiers. A field can optionally be declared static.
Using properties has a couple of distinct advantages: It allows for versioning if later you need extra logic. Adding logic to the getter or setter won't break existing code. It allows data binding to work properly (most data binding frameworks don't work with fields).
When should I use a property? In general, you should use properties if you need them to look and behave like a variable. Properties give you a level of abstraction to change the fields while not affecting how a class uses them.
If you have a Class object, you can obtain its public fields (including inherited fields) by calling getFields() on the Class object.
Because it breaks encapsulation -- this is why most people use accessors heavily. However, if you think it's the right solution for your task, ignore it (meaning the strict encapsulation complaints) and do what's right for your project. Don't let the OO nazis tell you otherwise.
123
It's really about future-proofing your code. When you say (emphasis mine):
What if I know for sure that I won't be redefining the field or adding to it (side effects are bad, right?) - shouldn't a simple field suffice?
That's an absolute statement, and as we know (as well as most static analyzers), there are only two absolutes in life.
It's just trying to protect you from that. If it is an issue, you should be able to tell the analyzer to ignore it (through attributes that are dependent on the analysis tool you are using).
36
Given the fact that current C# 3.0 allows for automatic properties whose syntax is like:
public int Property {get; set;}
the extra work required for using Properties over public fields is almost zero. The thing is you can never be completely sure a field won't be used differently or the accessor won't ever change and given the trade off in work there's no reason not to implement a property.
Anyway, the analyzer complains about things that in a high percentage (in this case like 99.99% of the cases) are bad programming practices... but anyway it is just complaining. Fields can be made public and there are some extreme cases where its direct use may be justified. As ever, use your common sense... but keep in mind the elemental rule for best programming practices ... Is there a really good reason to break the convention? If there's then go ahead, if not or if the answer is "it involves more work" then stick to the practice...
39
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
