views:

188

answers:

4

Note: I'm not talking about the names of event handlers. I'm talking about the names of the events themselves.

I tend to name events such that they describe what happened just before the event was raised. Adjectives tend to dominate this convention (CLICKED, SAVED, CHANGED, LOADED, etc).

Some competent peers have recently exposed me to the idea of naming events to describe what's about to happen (in response to the event). Verbs tend to dominate here (SAVE_DATA, GET_MEMBER, LOAD_RESULTS, SHOW_REPORT -- again, these are the names of events, not handlers or methods called from them).

I've decided the latter works well enough when you're in charge of both the event and the handler, and especially when there will only ever be one response you'll ever want to that event. Conversely, you can't very well name the event to match the verb (handler) that will follow if you don't have visibility to or control over it.

How do you name events, and why? Should one convention be enough (in a given shop, at the very least), or is it wiser to changed based on the size and scope of the code/project?

+1  A: 

I think there are two things in interaction here:

  1. Event - what has happened
  2. Action - what you are going to do

Naming event by how you are going to react is a BAD IDEA. Name event by what has happened. Otherwise it will confuse people. If the reaction changes in the future and the name of event stays the same, it will perplex developers.

Example:

  1. Event: Click(ed)
  2. Action: LoadProducts

If you were to name the event "ToLoadProducts", then change your action to "DisplayFilterForm" and forget to update the event, it will look like:

  1. Event: ToLoadProducts
  2. Action: DisplayFilterForm

It's clear it looks strange and untidy, as though somebody dropped the work in the middle.

Developer Art
+3  A: 

"Saving" for before event gets fired, and "Saved" after event happened.

epitka
I find that this improves understanding, but I also think it's necessary for uniformity throughout a given project. If the project has poorly named events, either refactor them or roll with it and keep up the poor naming scheme. Don't change in the middle.
Thomas Owens
Or use Pre... And Post... Scheme but as Thomas said be cosistent.
epitka
+1  A: 

Framework Design Guidelines suggest the following scheme:

Dzmitry Huba
+1  A: 

I name my events in the first way you described. This is because I want my handler to decide what to do with the event.

Ponting