编写内联事件处理程序是不好的做法
编写内联事件处理程序是不好的做法？
对于我来说，我更喜欢在事件处理程序中使用本地variables时使用它，如下所示：
我更喜欢这个：
// This is just a sample private void Foo() { Timer timer = new Timer() { Interval = 1000 }; int counter = 0; // counter has just this mission timer.Tick += (s, e) => myTextBox.Text = (counter++).ToString(); timer.Start(); } 而不是这个：
int counter = 0; // No need for this out of Boo & the event handler private void Boo() { Timer timer = new Timer() { Interval = 1000 }; timer.Tick += timer_Tick; timer.Start(); } void timer_Tick(object sender, EventArgs e) { myTextBox.Text = (counter++).ToString(); }
这是绝对好的 – 虽然有两个警告：
- 如果你在闭包中修改一个局部variables，你应该确保你明白你在做什么。
- 您将无法取消订阅活动
通常我只内联真正简单的事件处理程序 – 对于更多的事情，我使用lambdaexpression式（或匿名方法）通过调用更合适的方法来调用方法：
// We don't care about the arguments here; SaveDocument shouldn't need parameters saveButton.Click += delegate { SaveDocument(); };
在大多数情况下，我宁愿有像“timer_Tick（）”这样的单独的方法，但是我应该把它称为OnTimerTick（）：
- 当我读课时，小麦越来越清晰了。 “On”告诉我它的can事件处理程序。
- 在“inline”情况下，在方法中设置断点更容易。
- 在“Foo”承包商回来之后，这个事件被解雇很久了，我认为这不是承包商的范围。
但是，如果事件只会在方法声明之前被触发，并且事件被设置的对象有一个范围，那么声明的方法是有限的，那么我认为“在线”版本更好。 因此，我喜欢使用“在线”比较委托被传递给“sorting”的方法。
你把这两个样本放在一起。 很明显，第二个选项（你不喜欢）是最可读的。
代码的可读性和可维护性非常重要。 保持简单，尽可能容易理解。 Lambdaexpression式通常被大多数人认为是难以理解的。 即使他们是第二天性的，你也可能不会。
