Partager via

Do programmers really use Anonymous methods

  • Article

Anonymous methods provides a  elegant way to inline callback functions (delegates). Anonymous methods typically work in the situation where you don't have significant amount of code in the callback and hence don't want to take the trouble of defining a function for it. It makes maintenance a lot easier as you don't have to jump to the definition to see what the function does.

However, do people really use it? In my day-to-day coding I rarely use them. Because I rarely have callbacks that do small things that make it a good candidate for anonymous method. In my mind anonymous methods find use in the following scenarios

  1. Event handlers
  2. Delegates that need state
  3. Function generators (for using in functional programming style coding)
  4. In Predicates/Actions/Converter delegates

However most of the event-handlers I use are UI event handlers and they are inserted by the designer which does not create anonymous methods. I don't want to get into the trouble of manually changing them. Delegates that need state are also large functions and hence not a good candidate. In production code I would rarely use a function generator so that's out too.

The last one is generally a good candidate. Consider the following code that finds an element in a collection and then prints out the entire collection (List<>) 

 List<string> nameList = new List<string>();nameList.Add("Abhinaba");nameList.Add("Kaushik");nameList.Add("Samrat");
string searchName = "Abhinaba";
// find using a Predicate<T>bool found = nameList.Exists(                    delegate (string name)  {                         return name == searchName;  } );
// Iterate using Action<T> nameList.ForEach(delegate (string str) { Debug .Print(str);} );

Especially the last usage in ForEach brings out the elegance you can achieve using anonymous method. But still I'd guess that the usage of anonymous method will be very limited in production code.

Comments

  • Anonymous
    August 22, 2006
    I rarely use them.
    I was a little disappointed by their implementation in C#. I was hoping for some kind of CLR-level support instead of the auto-generated code. It is merely syntactic sugar -- something that I can do myself.

    Also, as syntactic sugar hiding the implementation, it is very tedious to debug when there is a problem. In the end, I often needed to look at the generated IL to find the issue.

    Now I am in the habit of writing it all out by hand. It saves me from potential debugging issues.
  • Anonymous
    August 22, 2006
    I use it quite a bit, mostly to handle such thing as state encapsulation:

    With.Transaction(delegate
    {
    //do stuff in transaction....
    );
  • Anonymous
    August 22, 2006
    I agree. I also mostly/solely use them for predicates.
  • Anonymous
    August 22, 2006
    The comment has been removed
  • Anonymous
    August 22, 2006
    Udi I agree with you. But in non-UI events I tend to do significant things like say log-something. Now since logging methods are commonly used at a lot of places I tend to have named wrappers over them and hence do not use anonymous methods for them.
  • Anonymous
    August 22, 2006
    The problem with Anonymous delegates is the verbosity. As in your example, using it inline for predicates is pretty alrite, no additional baggage there.

    But otherwise, the ugliness is really apparent at the callsite. You have to define and declare the delegate type. Unless type inference kicks in, this is a lot of work.

    Once we see lambdas and automatic type inference in C# 3.0, a lot of people will start using it. With LINQ, at least this is as concise as Ruby.
  • Anonymous
    August 23, 2006
    In my last post&amp;nbsp;I had discussed about anonymous methods.
    I had used the following code snippet...
  • Anonymous
    November 21, 2007
    In my last post I had discussed about anonymous methods. I had used the following code snippet to show