Is there any reason to use very simple properties over fields?

Question

I currently have this code written:

public class General
{
    /// <summary>
    /// Private variables.
    /// </summary>
    private const float fVersion = 1.3f;
    private static bool bMonitoring = false;

    /// <summary>
    /// Retrieves the current version of the application.
    /// </summary>
    public static float Version
    {
        get
        {
            return fVersion;
        }
    }

    /// <summary>
    /// Are we monitoring performance?
    /// </summary>
    public static bool Monitoring
    {
        get
        {
            return bMonitoring;
        }

        set
        {
            bMonitoring = value;
        }
    }
}

In case I check for General.bMonitoring or General.Version often (maybe.. over 100 times a second!) and really care about performance: is it good practice to leave my class written like that, or should I simply delete these properties and make the fields public?

I think you should not care about performance with this. But, accessing this values with get method is like calling method I guess. If you are directly calling your value from static class and const values, I think (must be verified) you will avoid a micro call to the method stuff and return cycle. — pix, Oct 24 '16 at 06:57
I actually do care because in my case, my application reads from another program's memory 1000 times a second (`while` loop with `Thread.Sleep(1);` so I prefer to never lag behind. — shavit, Oct 24 '16 at 06:59
http://stackoverflow.com/questions/295104/what-is-the-difference-between-a-field-and-a-property-in-c — Yuval Itzchakov, Oct 24 '16 at 07:01
Do you have any measurements taken that shows that accessing the fields have a significant improvement in performance over accessing the properties. — Ashley John, Oct 24 '16 at 07:02

score 2 · Accepted Answer · edited Sep 29 '17 at 17:02

2

In this case if you aren't going to add some logic to the getter or setter then I would use static fields. Performance will be the same.

But if later you need extra logic when you set ot get values then it preffer to use properties because it allows for versioning and it gives you Encapsulation according to OOP principles. Don't care about performance

For Monitoring property you can use Auto-Implemented Property like

public static bool Monitoring { get; set; }

but in this case you need to implement a static constructor (thanks to @Mafii)

    static General()
    {
        Monitoring  = false;
    }

or if you use C# 6.0 then just:

public static bool Monitoring { get; set; } = false;

edited Sep 29 '17 at 17:02

Sebastian Brosch

42,106
15
72
87

answered Oct 24 '16 at 07:04

Roman Marusyk

23,328
24
73
116

If I set `Monitoring` to an auto property, how would I initialize it as `false` though? – shavit Oct 24 '16 at 07:10
1

Yes, sorry. You are right. It is possible if you use C# 6.0 like: `public int X { get; set; } = x;` – Roman Marusyk Oct 24 '16 at 07:12
1

@MegaTron before C#6 you can use a static ctor iirc – Mafii Oct 24 '16 at 07:12
1

@shavit Glad to have been of help – Roman Marusyk Oct 24 '16 at 07:20
No need to add a static constructor or even the `=false`, it is the default value of a `bool` (a value type) and the backing field of the property will be initialized as such. On the other hand, if you wanted it to be `true` then you would need to. – pinkfloydx33 Oct 24 '16 at 08:37

score 1 · Answer 2 · answered Oct 24 '16 at 06:58

Don't worry about performance. Property access is (and should be) very fast and compiler may inline them.

Property is preferred over field not because of performance, but because encapsulation and it will really helps when later you need for example checking or make property computed.

More by Jon Skeet http://csharpindepth.com/Articles/Chapter8/PropertiesMatter.aspx

Is there any reason to use very simple properties over fields?

2 Answers2