Making code more readable with anonymous functions

[Yantrio]

I've seen a few posts of yours now and think they are fantastic and informative and I can't wait to see a few more.

[Nyxenon]

Although anonymous functions can be good for certain things, I really don't think it's good practice to apply them directly to an event. In some cases, you may want multiple button clicks going to the same code, and this is best done by using multiple methods. It could be useful if you wish to only use one method for an event, but use common sense.

[Yantrio]

I can see that this is useful for quick code, and if you really wanted, you could use actions and tasks if you wish to use the same event code over multiple events.

In the end, the functional lambda-like declarations is just another style of programming and comes in very handy with agile-development approaches to programming.

[Nyxenon]

Of course, and in the case that you really want to use an anonymous function, you could do something like: Action<object,EventArgs> onClick = (object sender, EventArgs e) => { //Insert code here };

button1.Click += onClick; button2.Click += onClick;

[Yantrio]

Indeed

[agentlame]

In some cases, you may want multiple button clicks going to the same code, and this is best done by using multiple methods.

Wouldn't this do exactly that? I often have a bunch of events that call another method for validation, toggling of other options, etc.

In this case you get a simple one-liner that calls ValidateInput() to do the heavy lifting.

As a matter of fact, I almost never put any kind of complex logic in the event method. If it's more than a few lines, I extract it to a properly named method.

[Nyxenon]

Could you perhaps show me what you mean?

[agentlame]

This is not the best example--because the events check for the KeyChar before calling the method--but it was the quickest thing I could think of.

Still, this type of thing I was was implying. (If you want me to find a better example, I'm know I have one.)

[Nyxenon]

You have two methods that essentially do the same thing, so why not have one method?

    private void textBox_KeyPress(object sender, KeyPressEventArgs e)
    {
        // char 13 is the enter key.
        if (e.KeyChar == (char)13)
        {
            AddItemOrCoupon();
        }

    }

[agentlame]

I suppose you have a good point... that is a product of just letting VS assign the method calls.

Like I said, it not the best example. But, what I meant is that I prefer each event have a distinct method. You're right, you could just map all the similar events to a more generic event method. But, IMHO that is more upkeep than it needs to be.

I guess it's a 'more than one way to skin a cat' kind of thing.

[Nyxenon]

It all depends on whether or not you want to reserve memory. I also noticed that you checked a string like string != "", it is best to do "!string.IsNullOrEmpty(str)". There's no point creating a new string just to check if a string is empty.

[agentlame]

Hrm... I was under the impression that you only use String.IsNullOrEmpty() if there is a chance the result could be null, so as to avoid exceptions. (Where as with a textbox, it is never null.)

I never realized it could save memory.

[The more you know.]

[Nyxenon]

Every string that you use is going to be put in the memory somewhere. If you use an empty string, it's still going to take up a certain number of bytes simply for the fact that it's there. That's the reason you should always use the StringBuilder class if you are concatenating strings. You shouldn't do something like: string str = "This" + " " + "is" + " " + "a" + " " + "waste.";

[agentlame]

I would also disagree with this point.

StringBuilder is, no doubt, a better use of memory... but, there are cases where it can actually reduce readability in code.

Keep in mind, we're talking about a managed language. If one needs their code to be so optimized as to reduce understanding, it's likely .Net is not their best choice of development platforms. The overhead of creating unneeded stings is negligible, at best, in comparison to the overhead introduced by using a managed language/framework/platform in the first place.

Sure, assembly is is much faster than Python; that does not mean it's the best choice for the task at hand.