event naming convention

[boxboy]

I am hoping someone from Microsoft could shed some insight into this
question.

Why did microsoft decide to use a verb based naming convtion for events
rather such as Close and Click for rather than prepending them with On as in
OnClose and OnClick?

The way it is now, I encounter a lot of naming conflicts/ambiguity when
trying to follow Microsoft's reccommened approach in naming my own events.

As I am writing this message, I am just trying to think of event names for a
socket class I am working on. It already has method names like Connect,
Disconnect, and Read. At first OnConnect and OnClose seem like the most
natural event names, but this goes against the standard.

You get the idea.

Why didn't Microsoft want to prepend On to event names? Many other
languages/tools have been doing this for a long time, and in my opinion its
quite natural.

What should I name my Connect, Disconnect, and Read events?

Thanks for reading.

 

[Jay B. Harlow [MVP - Outlook]]

Boxboy,

What should I name my Connect, Disconnect, and Read events?

I would use past tense Connected and Disconnected. Unfortunately Read is
both paste & present tense... Which allow for Connecting & Disconnecting
cancelable events...

Would Received work instead of Read? For a socket I would think in terms of
Receiving data instead of Reading data...

Why did microsoft decide to use a verb based naming convtion for events
rather such as Close and Click for rather than prepending them with On as in
OnClose and OnClick?

A derived class cannot raise a base class event, the convention is that the
Close event is raised by the OnClose method of the class. Because OnClose is
a method, it cannot be overloaded for the event itself. A benefit of OnClose
is that it is virtual, derived classes can override the method allowing
easier handling of the event in derived classes, and allowing derived
classes to have pre or post processing before the event itself is raised.

For details on the convention (not necessarily why) see:

http://msdn.microsoft.com/library/d...s/cpgenref/html/cpconEventUsageGuidelines.asp

http://msdn.microsoft.com/library/d.../cpgenref/html/cpconEventNamingGuidelines.asp

Hope this helps
Jay

 

[boxboy]

Boxboy,
I would use past tense Connected and Disconnected. Unfortunately Read is
both paste & present tense... Which allow for Connecting & Disconnecting
cancelable events...

Well, actually I already have a bool property named Connected, so I would have to use
some other name for the event.

Would Received work instead of Read? For a socket I would think in terms of
Receiving data instead of Reading data...

A derived class cannot raise a base class event, the convention is that the
Close event is raised by the OnClose method of the class. Because OnClose is
a method, it cannot be overloaded for the event itself. A benefit of OnClose
is that it is virtual, derived classes can override the method allowing
easier handling of the event in derived classes, and allowing derived
classes to have pre or post processing before the event itself is raised.

Yes I understand the protected virtual OnEventName design.

Let me explain further.

I come to C# from a Delphi background. I absolutely do not want to make or use C# as
Delphi (I understand C# is a totally different paradigm). Having said that, there are
many simlilarities between C# and Delphi. Both use single root object heirarchy, both
fully support PME, both were designed by Anders Hejlsberg.

In Delphi you typically would write a protected virtual method to call an event,
allowing derived classes to pre and post process event just as you described. The
difference was that the programmer would prepend Do infront of the method name to
create virtual protected methods like DoClose, DoClick and so on. The actual events
were then named OnClose and OnClick.

Honestly, when I read name like Click and Close I think of methods and that either
cause a Click to happen or a something to Close. In otherwords it is not immediately
obvious when read the name to know if it a method or event.

Do you see how the Mircosoft event naming guidelines make things messy as in the
example of Connect/Connected above?

I understand that Microsoft wanted change things down to the core with dotnet, and
one of their goals seems to have been to kill hungarian notation, but really I'm a
bummed that they made the descision not to prepend events with On when it seemed like
such a no-brainer.

What I am asking for is validation on the why Microsoft went with this descision, and
wanted to know if anyone would have preferred OnEventNames?

Finally, before someone replay saying I can name events any which way, that is
obvious. I just want to write code that other people feel would comfortable with
should I ever work in a team environment using C#.

Thanks again for reading.

 

[Jay B. Harlow [MVP - Outlook]]

boxboy,

Well, actually I already have a bool property named Connected, so I would have to use
some other name for the event.

I would use IsConnected for the property.

Do you see how the Mircosoft event naming guidelines make things messy as in the
example of Connect/Connected above?

Yes I do, however I have never really had a problem with it, as you are
suggesting you have. And yes I have created tons of classes with events, and
properties and similar named things...

What I am asking for is validation on the why Microsoft went with this descision, and
wanted to know if anyone would have preferred OnEventNames?

I cannot offer any "validation"...

Remember conventions & guidelines are just that conventions & guidelines. If
you really want to name your event OnEvent name it OnEvent. If you want to
name the virtual function DoEvent, name it DoEvent. My feeling tends to be
as long as you are consistent within your project, team, department,
organization. Does it really matter what the Microsoft Guidelines state?

I tend to (mostly) follow the Microsoft Guidelines, not because they are the
*Microsoft Guidelines* but because then my code is consistent with the
framework, other .NET developers can pickup my code and be reasonable
familiar with it. I don't blindly follow the Guidelines, for example they
suggest using the same name for Fields & Properties, which may work in C#,
however this fails in VB.NET. Hence I follow another convention (m_field
instead of field).

Finally, before someone replay saying I can name events any which way, that is
obvious. I just want to write code that other people feel would comfortable with
should I ever work in a team environment using C#.

Too late ;-)

I suspect because I have not really used Delphi, that event naming is not
"messy" for me. Instead of Delphi I've had MFC, VB & Java.

Hope this helps
Jay