When to use private properties (with no special logic)

Question

Recently I've been reading some threads about always using properties instead of public fields in C#, but what about private properties? Of course, there are a few threads about it, but they almost always talked about additional logic / lazy-loading etc.

Let's say I have a readonly field that will be accessed all around the Program class, but (at least for now) it's not used anywhere else:

static class Program
{
    private static readonly Canvas canvas = new Canvas(100, 30);
    // Canvas is like the main class of my game, there can be only one instance of it

    static void Main()
    {
        // ...
        canvas.DoSomething();
        // ...
    }

    // ...
    // Many other references to "canvas" here
}

or should I do something like this:

private static Canvas Canvas { get; } = new Canvas(100, 30);

The second option means that I can easily make this public, which I might or might not do in the future. And what about other private fields? Are there any rules or guidelines about what should be a private property or not? Or should I declare everything as a field because it's private (although it feels public-ish)?

Just for clarification:

I'm not making a reusable library, just a console game;
I'm not going to implement any logic about getting / setting the value;
I'm writing the Canvas class myself, it's not external.

That’s more of a software engineering question, than a question for StackOverflow, see https://softwareengineering.stackexchange.com/questions/160876/should-you-make-private-properties. That being said, as stated by Eric Lippert [here](https://stackoverflow.com/a/3310469) a very tangible advantage of private properties (with a setter) is that you can better debug them, when you want to know who sets a value and when. — ckuri, Nov 02 '19 at 10:11

score 1 · Accepted Answer · 2019-11-02T10:33:44.557

Using private properties is useless because only the current class members have access to it and it is read and write.

Unless you want only to initialize it in constructors or at declaration level, and disallow the write in others methods, so you can write:

private MyField { get; }

The difference between declaring a readonly field and such property is that the property read accessor is a method so it causes a CPU proc call tick consuming on each access, that does not require a readonly property.

So it is a matter of speed performance else it is the same finality.

Here is a test class:

public class Test
{
  private readonly int MyField = 10;
  private int MyProperty { get; }
  public Test()
  {
    MyProperty = 10;
  }
  public void Method()
  {
    var value1 = MyField;
    var value2 = MyProperty;
  }
}

And here the IL code generated by the compiler:

// int myField = MyField;
IL_0001: ldarg.0
IL_0002: ldfld int32 ConsoleApp.Test::MyField
IL_0007: stloc.0

// int myProperty = MyProperty;
IL_0008: ldarg.0
IL_0009: call instance int32 ConsoleApp.Test::get_MyProperty()
IL_000e: stloc.1

With a readonly field there is only a load of the value into the stack, that the CLR replaces by a target processor load into a register instruction, that is fast (MOV).

With a property there is a .NET method call, that the CLR replaces by a target processor procedure call instruction, that eats lots of CPU ticks as well as the return (CALL/RET).

.method private hidebysig specialname instance int32 get_MyProperty () cil managed 
// return MyProperty;
IL_0000: ldarg.0
IL_0001: ldfld int32 ConsoleApp.Test::'<MyProperty>k__BackingField'
IL_0006: ret

So a property needs many more CPU cycles than a readonly field, but the result is the same in terms of operation (I will say a wrong value because I don't remember for x486 and it is old, but imagine it may be ~5 to 20 times slower to have an idea).

Therefore it is a matter of preference if speed is not critical. You can change to public without problem, the high level design remains the same: there is no difference else the speed and the look.

That said, remember that public properties are required for the Visual Studio designer, components design and serialization for example. So using properties may be a gain of time as well as be more smart.

https://superuser.com/questions/643442/latency-of-cpu-instructions-on-x86-and-x64-processors

Well, I don't care about performance *that* much, I was asking more about code cleanliness and readability, but thanks (giving you an upvote) — Volper, Nov 02 '19 at 10:30
Thanks, I just added a consideration at the end for a reason to use properties that may be marked as public in the future. — , Nov 02 '19 at 10:32
Yeah it's hard not to notice if someone is making a million of edits per minute :D — Volper, Nov 02 '19 at 10:33
Sorry, there is no preview button and I like improving things from real point of view and from others questions. — , Nov 02 '19 at 10:34

score 1 · Answer 2 · answered Nov 02 '19 at 10:34

A property is a wrapper above a private variable.

A private property is as good as a private variable. There is no difference. If you do not intent to use the variable outside the class, then just use the variable.

Also you have used readonly. The only purpose of readonly is that it only be initiated inside the constructor.

I hope that answers your question.

When to use private properties (with no special logic)

2 Answers2