Public Read-Only Fields - Best Practice Considerations

[Smithers]

I understand there is no "right" or "wrong" answer to the question posited
below. But I'd appreciate some feedback on the "best practice"
considerations - if there are any.

So here goes:
Are public readonly properties generally frowned upon? If so, then are there
any generally accepted cases where they are considered as okay?

Please consider the following class and notice it has two properties -
EventMessage1 and EventMessage2.

public class MyFabulousEventArgs : System.EventArgs
{
// Declarations
string eventMessage2 = string.Empty;
public readonly string EventMessage1;

// constructor
public MyFabulousEventArgs(string msg1, string msg2)
{
EventMessage1 = eventMessage;
eventMessage2 = eventMessage2;
}

// Properties
public string EventMessage2
{
get { return eventMessage2; }
}
}


My tendency is to implement properties as EventMessage2 above. But in the
case of a custom EventArgs class, it seems quite reasonable to implement as
a public readonly field.

Your Thoughts (not only on the above scenario, but on the general question
of public readonly fields) ???

Thanks!

 

[Jon Skeet [C# MVP]]

I understand there is no "right" or "wrong" answer to the question posited
below. But I'd appreciate some feedback on the "best practice"
considerations - if there are any.

So here goes:
Are public readonly properties generally frowned upon? If so, then are there
any generally accepted cases where they are considered as okay?

Read-only properties are perfectly normal, and occur all over the
framework.

Read-only fields are less common, but I think they're reasonable for
constants such as string.Empty. I wouldn't expose an instance field as
public though, personally.

 

[Ben Voigt [C++ MVP]]

I understand there is no "right" or "wrong" answer to the question posited
below. But I'd appreciate some feedback on the "best practice"
considerations - if there are any.

So here goes:
Are public readonly properties generally frowned upon? If so, then are
there any generally accepted cases where they are considered as okay?

Please consider the following class and notice it has two properties -
EventMessage1 and EventMessage2.

public class MyFabulousEventArgs : System.EventArgs
{
// Declarations
string eventMessage2 = string.Empty;
public readonly string EventMessage1;

// constructor
public MyFabulousEventArgs(string msg1, string msg2)
{
EventMessage1 = eventMessage;
eventMessage2 = eventMessage2;
}

// Properties
public string EventMessage2
{
get { return eventMessage2; }
}
}


My tendency is to implement properties as EventMessage2 above. But in the
case of a custom EventArgs class, it seems quite reasonable to implement
as a public readonly field.

Your Thoughts (not only on the above scenario, but on the general question
of public readonly fields) ???

Your scenario doesn't show proper equivalency.

What you really have is, in effect:

public string EventMessage2
{
get { return eventMessage2; }
internal set { eventMessage2 = value; }
}

To get rid of private mutability, you'll have to define the backing field
read-only in addition to providing the get-only property.

 

[GlennDoten]

internal set { eventMessage2 = value; }

Holy crap! How'd I miss that syntax (the "internal" part). Sweet!

Is that new to C# 2.0?

 

[Jon Skeet [C# MVP]]

Holy crap! How'd I miss that syntax (the "internal" part). Sweet!

Is that new to C# 2.0?

Yup, more's the pity. It should really have been in from the start.

Jon