Question

I am developing a CLS-compliant types library and I have a class inside It, which contains private, protected and public fields and properties. I use underscore symbol (_) as prefix for private or protected fields and little first letter to distinct their from properties with same names. It looks so:

class SomeClass
{
private int _age; //Here is OK

public int Age { get { return this._get; } }
}

But when I try to use protected fields I collide with a next problem:

class SomeClass
{
protected int _age; //Here is NOT CLS-compliant (because of _ can't be the first symbol of identifier)

public int Age { get { return this._get; } }
}

Then I tried to do in such way:

class SomeClass
{
protected int age; //Here is NOT CLS-compliant (because of age and Age differ only in one symbol)

public int Age { get { return this._get; } }
}

Please, tell me, what is right CLS-compliant notation or convention between developers for such cases? Have I to use prefixes in C-style like l_age?

Answer 1

Here’s a more correct version, IMO:

private int _age;
public int Age {
    get { return this._age ; }
    protected set { this._age = value; }
}

or simply:

public int Age { get; protected set; }

If you properly encapsulate it, then it doesn’t matter what the field is called, as nothing outside that type can see it.

---

In comments, the question of events is then raised, with the example:

protected EventHandler<StateChangedEventArgs> _stateChanged;
public event EventHandler<StateChangedEventArgs> StateChanged
{
    add { lock (this.StateChanged) { this._stateChanged += value; } }
    remove { lock (this.StateChanged) { this._stateChanged -= value; } }
}

Here I again assert that there is no reason for this field to be protected; the event does not belong to the derived class. It has 2 sensible operations it can want to perform:

1. invoke the event
2. subscribe/unsubscribe to the event

The former should be done via the On* pattern; the latter should just use the regular accessors (otherwise it violates the lock). Also, even if we assume that lock(this.StateChanged) is a typo (that would be a really, really bad thing to use as the lock object -it would not work at all), note that in C# 4.0 the compiler has a much more efficient lock strategy inbuilt (that uses Interlocked rather than Monitor) when you write a “field-like” event (i.e. no explicit add/remove). Consequently, the preferred approach here would be:

public event EventHandler<StateChangedEventArgs> StateChanged;
protected virtual void OnStateChanged(StateChangedEventArgs args) {
    var snapshot = StateChanged; // avoid thread-race condition
    if(snapshot != null) shapshot(this, args);
}

and… that’s it!

• if the subclass wants to subscribe/unsubscribe (not ideal, but meh) it just uses StateChanged += and StateChanged -=
• if the subclass wants to invoke the event, it calls OnStateChanged(...)
• if the subclass wants to tweak the event logic, it adds an override to OnStateChanged

no need for any non-private fields.