views:

64

answers:

6

Are there design guidelines on how to name methods that trigger an event in .NET? In different examples I've seen all of:

OnPropertyChanged()
FirePropertyChanged()
TriggerPropertyChanged()
RaisePropertyChanged()

Of course this is not hugely important, but I'd like to do it the "right" way and not confuse others with unusual naming conventions. =)

+3  A: 

OnPropertyChanged() sounds like the associated event handler.

I'd go with RaisePropertyChanged().

Bobby
+1  A: 

Why do you need a method to raise an event?

If you're performing an action from outside an object, then the action you perform should cause the event to be raised without there being an explicit call to an "event-raising" method.

If your event is being raised internally simply have a RaiseEvent line when you want to raise the event, there's no need to call a method to do so.

If you have an object which is receiving a call from another object purely to cause it to raise an event, then I'd suggest that you have a problem with your encapsulation...

EDIT: If you're using a method as part of implementing iNotifyPropertyChanged (rather than just raising the "PropertyChanged" event, which is all iNotifyPropertyChanged requires...) then why not name the method "notifyPropertyChanged" so as to show that it's part of that implementation?

EDIT2: MSDN code which follows this convention: How to: Implement the INotifyPropertyChanged Interface

Frosty840
A common example is the INotifyPropertyChanged implementation that inspired the names in the question. That is my object raises events internally, and I am asking for the name in the "RaiseEvent" line. Maybe it is too internal for a naming guide...
Jens
It is not done by one line, you need to check if the eventHandler is not empty and create and populate your specific EventArgs.
elsni
Another common example is having such a method available as Protected, for classes that expect to be subclassed, so that the subclasses can raise the event.
Damien_The_Unbeliever
+2  A: 

It's OK and common practice to call it OnPropertyChanged. It differs in signature from an event handeler. http://msdn.microsoft.com/en-us/library/ms743695.aspx

Henrik
Thanks for the link! I always used examples from outside the msdn.
Jens
+1  A: 

Other than OnPropertyChanged() which atleast i find to be a bit misleading, you could probably use any of the others.

However, what is probably more important is consistency of usage of the notation across your entire application.

If you say choose FirePropertyChanged", what will be most critical from a maintainability perspective is that the pattern of all property raising methods being prefixed with "Fire" in your entire application is enforced!

InSane
+5  A: 

You should use OnPropertyChanged according to MSDN, CodeProject and the book Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries (2nd Edition).

EDIT: The quote from CodeProject only refers to the naming of the event, e.g. if your event signalizes that a alarm has happened it should be named AlarmRaised.

Please note that in this article, events are described as "raised" (not "fired" or "triggered"). This convention comes from the team of developers who authored much of the .NET Framework (Cwalina and Abrams, 2006). They prefer the term, "raise," because it doesn't have the negative connotations of the expressions, "fire" or "trigger."

RoXX
Funny enough, the both linked articles use "On..." for the method. =) (Compare section 7 in the CodePlex article, and the example on MSDN).
Jens
This is contradicting information, MSDN uses RaiseXYZ as the event name and OnRaiseXYZ as the associated invocation method.
Johannes Rudolph
thanks @Jens ,@Johannes Rudolph the quote was really confusing
RoXX
A: 

I'd use FireOnPropertyChanged().

elsni