I was integrating a component from another developer on my team, recently, and I came across a common naming convention and event implementation. The naming convention included a "DataSource" property on a UI control and a an event with an EventHandler delegate signature.
I have a hunch that the use of EventHandler and names like “DataSource” are there because this developer was following the standards that were built into the .NET framework. These standards are great when you are building generic controls in a UI layer and highly reusable frameworks where those controls can be applied across a large number of applications and business needs. These standards don’t give much value in the context of the business process the represent, though.
When building business applications and controls for a specific business purpose, names like "DataSource" mean that I may have to look at the return data type to see if it’s something that I might be able to use, and may mean that I may need to look at the implementation to see if it’s really what I want. If a method or property name is geared towards the business need that it represents, it’s less likely that I’ll have to dig around to see if it’s what I need.
So, rather than calling it “DataSource”, something like “WidgetUsageHistory” may be a more direct statement of what this property really represents.
Similarly, a business process related event could provide a method signature like this:
public delegate void WidgetCreatedDelegate(Widget widget);
public event WidgetCreatedDelegate WidgetCreated;
This would have better business value in the code, because it tells me that I can subscribe to this event and be notified of a Widget being created, and know which Widget was created.