Should I stop breaking .NET events guidelines? [closed]

Question

Over and over I find myself implementing events in C# following the guidelines and then falling back to a simpler implementation using just Action when the client code does not need any of the benefits added by the guidelines.

Arguably, I'll add that omitting the sender object unless it is actually required is a good thing because it promotes decoupling of triggers and handlers. More in general, I think it is a good habit to avoid writing code that is not needed.

I don't mean that the guidelines should be always dismissed, there are benefits in following them (see links below). My question is if I should always follow it.

The example below shows how terse the "naive events" patterns is compared to the guidelines pattern.

// This is neat
class NaiveEvents
{
    public event Action<string> OnAlert;
    public void TriggerOnAlert(string message)
    {
        OnAlert(message);
    }   
}

// Is this bloated?
class ProperEvents
{    
    public event EventHandler<OnAlertEventArgs> OnAlertEvent;

    public void TriggerOnAlert(string message)
    {
        OnAlertEvent(this, new OnAlertEventArgs(message));
    }

    public class OnAlertEventArgs : EventArgs
    {
        private readonly string _message;
        public OnAlertEventArgs(string message)
        {
            _message = message;
        }
        public string Message { get { return _message; } }
    }
}

class EventsDemo
{    
    public static void DemoNaiveEvents()
    {
        var ev = new NaiveEvents();
        ev.OnAlert += (msg) => { Console.WriteLine(msg); };
        ev.TriggerOnAlert("Hello World");
    }

    public static void DemoProperEvents()
    {
        var ev = new ProperEvents();
        ev.OnAlertEvent += (sender, args) => Console.WriteLine(args.Message);
        ev.TriggerOnAlert("Hello World");
    }
}

See the Guidelines: http://msdn.microsoft.com/en-us/library/w369ty8x.aspx

Benefits: What are the benefits of having events conforming to Net guidelines?

Thanks!

Answer 1

Guidelines or conventions are arbitrary and non of them can fit all situations, environments, solutions or points of views, but that's the reason of creating these documents: standarization.

Sometimes some guideline would seem useless, but my humild opinion is never following a guideline and/or convention will be worst than don't doing so.

Maintainability, code re-use, predictability, readability and the absence of discussions everyday because every developer has his/her opinion of everything in trivial things, for me, has more value than anything.

Focusing in your current question, and based on what I said above, even if there's no performance or design quality benefit, I would suggest and recommend that global guidelines and conventions must be followed if some software development is for professional purposes. And if it's for open source audiencie, these should be followed too.

As an enthusiast and professional developer, I love writing, reading and maintaining code that follows de facto coding standards, because I know everyone will understand my work - obviously, documentation is a plus! -.

Answer 2

My design in this(and similar situations) usually differers for application and library code.

For reusable libraries I tend to follow the guidlines more, since that gives better versioning semantics. And changing the public api of a library is rather annoying.

In application code I tent to compromise more. Refactoring such an event handler used only in a single solution isn't that much work. So using your simplified pattern is OK IMO.

Answer 3

From my point of view the biggest benefit of following the pattern is that you can have interchangeable event handlers. For example if you have defined a

public void OnClick(object sender, EventArgs e)

method that handles a click event somewhere it would be trivial to wire it to your OnAlert event if needed without having to wrap the signature. This is however trivial to do in C# > 3.0 using lambdas so the gain can be small. Back in the day before anonymous delegates this was harder to do so it made sense to follow the guideline