Proper naming convention for a .NET Delegate type?

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);

Answer 1

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...

Answer 2

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.

Answer 3

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.

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.

Answer 5

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.

Answer 6

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.