This project is read-only.

Are the samples really "the right way to do it"?

Topics: Using
Feb 5, 2015 at 4:36 PM
Edited Feb 5, 2015 at 5:00 PM
The code samples in the Enterprise Library v6 samples implement the "EventSource-derived class should have a readonly singleton named Log, and should not have a public constructor" pattern like this:
    private static MyCompanyEventSource _log = new MyCompanyEventSource();
    private MyCompanyEventSource() { }
    public static MyCompanyEventSource Log { get { return _log; } }
I wonder what makes that preferable to
    public static readonly MyCompanyEventSource Log = new MyCompanyEventSource();
    private MyCompanyEventSource() { }
Is it just that properties that only have a get block (but are not otherwise marked "readonly") are "more cool" than readonly fields (that are explicitly readonly)?

It is not my intent to start a coding-style war. I am just trying to understand why the sample was written as it was, instead of something that is shorter (and IMHO more clear).

Thank you.

=== Edit === I have noticed that some of the other samples do it with a readonly field instead, so apparently this is not something where the "right way" has been fully determined.
Feb 5, 2015 at 11:06 PM
It does not make difference. You can use the readonly field.