18

A lot of people follow the following paradigm:

are always private.

are only used to expose fields, thus should only be public. There are plenty of exceptions to this rule (lazy loading, for example).

With auto-properties, I've found it possible to never use fields. If I need my fields to be very basic, I just use auto-properties

private int? ThisIsMoreOrLessAField { get; set; } // Actually a private property

What is generally preferred? Some people like fields because if anyone ever decides to change a field and make it public, it's very obviously bad code and easy to recognize in code-review. It's also easy to look at fields and recognized that it's private to the class. If your properties can be private, that breaks that paradigm. You have to do further inspection to determine if it's public or private.

I'm having a hard time convincing myself either way.

Improve this question
7
  • 3
    What is generally preferred is to use fields for what they are designed for (private state), and to use properties for what they are designed for (exposing a public API).
    – Robert Harvey
    Commented Apr 6, 2018 at 2:49
  • Fields may need to be public for interop and making them public can be useful in some optimization scenarios (using structs where any value is a valid state, in particular taking advantage of C# 7.2 ref semantics). Properties might not be for exposing fields, some initialize lazily, some delegate to another object, or some other stuff, I remember a case where I had to implement a property as a bit check on a field. Code beats Data. Private properties are useful for lazy initialization, and can be useful to ease debugging (since you can break on get and set) or to facilitate data in inspection.
    – Theraot
    Commented Apr 6, 2018 at 3:01
  • Lazy loading is not exception, cause you can use private field of type Lazy<Your type>, which removes need to use property.
    – Fabio
    Commented Apr 6, 2018 at 4:46
  • @Fabio: Lazy<T> exposes its value as a property, so that's a bit of a circular argument.
    – whatsisname
    Commented Apr 6, 2018 at 16:24
  • There are certain places where you must have properties instead of fields, simply because of they way they are accessed via reflection. This includes the use of a property grid, type descriptors, custom type descriptors, etc. The .net framework guidelines specify to always use properties for public APIs.
    – Frank Hileman
    Commented Apr 6, 2018 at 21:26

1 Answer 1

Reset to default
13

As Robert Harvey said, what is generally preferred is to use fields for what they are designed for (private state), and to use properties for what they are designed for (exposing a public API).

The two exceptions I find in practice are:

  • Derived fields, where you do a little math on get and set. Sure, you could use get and set functions, but if I wanted to write Java I'd use Java.
  • Situations where you need to keep track of or fire events when your fields are modified. A simple example is logging when a field is changed or counting when something is accessed. I'm guessing that doesn't happen often in line-of-business type apps, but it can be common if you are doing something such as talking to a hardware device where you hide a lot of the details behind the interface, but need to still keep track of those fields over time for debugging.

Notice in those examples something else happens besides a get or set when the properties are used. Properties in C# are basically snazzy syntax which wraps getVar() and setVar() as seen in Java and COM. In C#, they provide the means to introduce some logic when the properties are used, but to otherwise be treated as an ordinary variable.

If you just have a variable with no logic on set or get, use a field.

Improve this answer
2
  • Another factor for "why private properties" is that VS provides CodeLens for them. I'm still not super clear on "why not private properties", other than being against tradition. Perhaps, the indirection causes a slowdown (or would it be inlined by JIT)?
    – Iain
    Commented May 12, 2020 at 4:54
  • My personal feeling about this is, "Why not private properties"? Because it's bad API design. private fields have a specific purpose, as do private properties. Make private fields "fields" until there is a need for something more. The accepted answer here is a good example.
    – Mohaaron
    Commented May 11, 2023 at 17:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.