Exposing common values from a custom structure/type

Question

One of my projects has a value type/struct that represents a custom identifier string for a video format. In this case, it's going to contain a content type string, but that can vary.

I've used a struct so it can be strongly type when it's passed around, and perform some sanity checks on the initial string value.

public struct VideoFormat {
    private string contentType;

    public VideoFormat(string contentType) {
        this.contentType = contentType;
    }

    public string ContentType {
        get { return this.contentType; }
    }

    public override string ToString() {
        return this.contentType;
    }

    // various static methods for implicit conversion to/from strings, and comparisons
}

As there are a few very common formats, I've exposed these as static read only fields with default values.

public static readonly VideoFormat Unknown = new VideoFormat(string.Empty);
public static readonly VideoFormat JPEG = new VideoFormat("image/jpeg");
public static readonly VideoFormat H264 = new VideoFormat("video/h264");

Is it better to expose the common values as static read only fields or as get only properties? what if I want to change them later? I see both methods used throughout the .Net framework, e.g. System.Drawing.Color uses static readonly properties while System.String has a static read only field for String.Empty, and System.Int32 has a const for MinValue.

(Mostly copied from this question but with a more specific and not directly related question.)

Napiform

Possibly related: C#: Static readonly vs const, How best to implement publicly accessible constants in C# – Napiform

Answer 1

Properties are a good idea unless you are declaring something that never changes.

With properties you can change the inside implementation without affecting programs consuming your library and handle changes / variations. Consuming programs wont break and wont require to be recompiled.

e.g. (I know this is a bad example but you get the idea..)

public static VideoFormat H264Format
{
   get{
         // This if statement can be added in the future without breaking other programs.
         if(SupportsNewerFormat)
             return VideoFormat.H265;

         return VideoFormat.H264;
    }
}

Also keep in mind that if you decided to change a field to a property in the future, consuming code breaks.

Vacla

In this case, fields will work the same way as properties won't they? – Napiform

How will you put logic in a field and return different result based on that logic? – Vacla

Sorry, I was referring more to the value itself, allowing you to change it. Both can be changed (at design time) and apply in any callers? – Napiform

Yes both can be changed - but you can't convert a field to a property in the future, without caller being recompiled. – Vacla