Proper naming convention for a .NET Delegate type? [closed]

Question

By convention classes are often named like nouns, methods like verbs and interfaces like adjectives.

What is the common naming convention for a delegate? Or what's a good way to differentiate its name when delegates are listed among types and other things?

My immediate assumption is to name a delegate more likely an adjective because a single method interface can often be replaced with a delegate.

Some thoughts:

delegate object ValueExtracting(object container);

delegate object ValueExtractor(object container);

delegate object ValueExtractionHandling(object container);

delegate object ValueExtractionHandler(object container);

Subtonic

Answer 1

Personally I use a couple of different patterns:

[Task][State]Handler - UITaskFinishedHandler

[Event]Handler - ControlLoadedHandler

[Function Name]Delegate - DoSomeWorkDelegate - used when I need to create a delegate for calling a function on a different/new thread

[Task]Callback - ContainerLoadedCallback - used when control A starts an action which control B does most of the work and control A has passed a dependency in to control B (i.e. ControlA may have passed a UI container for ControlB to fill and needs notification to actually show the container)

When you have a project that uses a lot of multi threading or async WCF calls you can end up with a lot of delegates floating around, so it is important to adopt a standard that at least makes sense to you.

Petunia

+1 It's a nice convention. I'm also agree with the @Aaronaught answer below where a delegate uses by an event type should have the 'EventHandler' suffix instead of just 'Handler'. – Taryn

"[Function Name]Delegate" violates CA1711, unfortunately. I like to use "[Function Name]Func" or "[Function Name]Action" depending on if it has a return type or not. – Height

That is probably single most usefull (and shortest) convention I have seen so far. +1 from me. Thanks for sharing @Petunia – Narcosynthesis

The code rules tell you not to suffix any delegate with Delegate learn.microsoft.com/en-us/visualstudio/code-quality/… – Otiose

@MelbourneDeveloper That's a useful reference but note that it was published for analyzers/compilers/products that were released 6 years after my answer. Also when you have a number of delegates floating around because the tech stack relies heavily on multi-threading and it doesn't provide any built in compile time supports then the Delegate suffix is quite useful. – Petunia

When the answer was published is irrelevant. Microsoft hasn't explain why you shouldn't suffix delegate types with Delegate, but they are clear about it. It would be good if we could find out why they actively discourage this now. – Otiose

@MelbourneDeveloper probably due to them open sourcing a bunch of their code - they want to ensure any contributions are of a very high quality and there's no misunderstanding with type names. – Petunia

@MelbourneDeveloper tell that the guys who created the RequestDelegate for asp.net-core ;-] – Formalism

Answer 2

Microsoft's Framework Design Guidelines - the naming almanac for me, says the following on the topic:

√ DO add the suffix "EventHandler" to names of delegates that are used in events.
√ DO add the suffix "Callback" to names of delegates other than those used as event handlers.
X DO NOT add the suffix "Delegate" to a delegate.

Margarito

Funny that MS says 'DO NOT add the suffix "Delegate" to a delegate', but in this example they have a delegate called ProcessBookDelegate... – Larine

@Larine the same story with RequestDelegate in asp.net-core - so much to consistency and coding conventions. I guess the don't even read their own docs. – Formalism

Answer 3

Since a delegate is something that performs an action (a verb), the delegate should be named what you would call something that performs that action. Take Converter<TInput, TOutput> for example. The verb is Convert. The thing that does the converting is called a converter, hence the name of the delegate.

Had

Answer 4

This depends on a few things.

If the delegate is going to be used as an event, it should always be referred to as an EventHandler subtype, for example:

public delegate void ValueExtractingEventHandler(object sender,
    ValueExtractingEventArgs e);

If it's not an event, then the MS coding guidelines (which I can never seem to find the right copy of on Google) explicitly recommend against including words like "delegate" or "handler" in the delegate name, except in the special case of EventHandler types.

Normally, delegates should be named after actions, which would be like ValueExtracting (if the delegate happens before the value is extracted) or ValueExtracted (after extraction).

The Func<T1, T2, ..., TResult> delegate syntax is also becoming more common, but unless you have 4 or more parameters going into it, you don't need to declare your own at all - just use an existing one:

object ExtractObject(object source, Func<object, object> extractor);

This syntax is best when the delegate is being used as a closure. The delegate itself doesn't have a very interesting name, but the argument is an agent noun (extractor, provider, evaluator, selector, etc.)

Most delegate usages fit into one of the above categories, so figure out which one it's being used for choose appropriately.

Tamis

Answer 5

I never thought about it, mostly because I just use one of the EventHandler<T>, Func<T>, or Action<T> overloads and never bother defining my own. I would probably pick ValueExtractor from those you've listed. This makes it sound more like an object, and when you invoke it you'll be using that object to perform an action. For example:

ValueExtractor extractor += Blah;
var value = extractor(data);

Additionally, most of the built-in delegates are named like nouns as well. When in doubt, follow the .NET framework.

Juieta

Answer 6

Based on Enumerable.Sum, I'd pass the delegate as a Func<object, object> and name the parameter selector:

void Foo(Func<object, object> selector) ...

If you have to make your own delegate for it, I'd go with ValueExtractor since that's the most descriptive name for what it does.

Erivan

These generic delegates (Action and Func) are fine 95% of cases. There are some cases where they are wildly insufficient though - that is when the delegate has complicated signature AND gets passed around a lot. Basically, what each argument does should be obvious, if it is not, making a named delegate is a good idea. – Princedom

Answer 7

I would go with ValueExtraction..
I've Never thought why, but I guess because you're storing an operation and it should be a noun.. strictly this is not an operation, I know...

Kaz

Answer 8

In case of Events (with Delegates) Windows Forms uses following convention:

Delegate:

public delegate void MouseEventHandler(object sender, MouseEventArgs e);

Event:

public event MouseEventHandler MouseClick;

Event Listener:

this.MouseClick += new System.Windows.Forms.MouseEventHandler(this.Form1_MouseClick);

Bostic