C# fields vs. properties: a small Visual Studio productivity tip

When modeling data inside a C# class, fields are the simplest option. However, in Visual Studio, using properties instead can give you a small productivity boost.

Declaring a field is straightforward:

public class Person
{
    public string Name;
}

This works, but Visual Studio does not show CodeLens reference information for fields. You won't see how many places read or write the field directly from the editor.

However, if you switch to a property:

public class Person
{
    public string Name { get; set; }
}

...the story changes. Now Visual Studio shows CodeLens information above the property, including how many references it has. This makes it easier to understand usage and navigate a larger codebase.

This is especially useful during refactoring or when working in unfamiliar code. You can quickly see where a value is used without running a full search.

There are also general design reasons to prefer properties:

• You can later add validation or logic without changing the public API.
• You can control access with private set; or init;.
• It aligns with common .NET conventions and XML, JSON, BSON, etc. serializers.

Possible drawbacks include:

• Slightly more verbose than fields.
• Auto-properties still generate a backing field, so they are not fundamentally "simpler".
• In very performance-critical or low-level scenarios, direct field access may be preferred.

In practice, properties are usually a better default. The added tooling support in Visual Studio (CodeLens) is a small but very useful bonus.