Microsoft has done a good job when it comes to event naming within the BCL by following a common naming pattern: the gerund form of the verb is used during the act of doing something (i.e. Form.Closing), whereas the past tense is used after the act has completed (ala Form.Closed).  They've also done a fairly good job of encapsulating the full lifetime of events for a set of actions, and it's fairly intuitive to find what you are looking for in the documentation.

Recently I've been fooling around with the application settings classes in a Windows Forms application, but noticed a deviation from this practice for reasons that are beyond me, specifically the events exposed by the ApplicationSettingsBase class.  I'll let you glance at the list for a second or two, the missing event should be pretty obvious.  I'll wait...

Figure it out?  There is no corresponding SettingsSaved event.  Granted how I was going to use an event like that if it existed may be just flat out wrong from a design standpoint, but it certainly would feel right if that event existed, and there's a lot to be said about writing code that feels right.  In this case I need to have some configuration settings that are being saved from an options form applied immediately to various controls, so it makes sense not only to go ahead and apply the new changes, but persist them to disk as well.  This is easy enough to code around by using my own events, but it's still a little odd that MS excluded is, especially since there is a SettingsSaving event.  Puzzling.