Hey all, A friend and I were having a little discussion about the merits of prefixing methods with the word "On" to give the illusion that it's an event. We've looked at a few places for examples and have seen both cases for and against the practice. Two examples: C# / WinForms uses a Paint event with an OnPaint method to raise the Paint event which calls your custom methods through a delegate. C++ / MFC uses a virtual OnPaint method that each derived class overrides to do it's custom painting. So where does it end? What makes the "On" prefix a distinction from other methods? OnInput, ProcessInput, and HandleInput all seem valid to me. Discuss.

I guess it all depends on personal choice. Each programmer has their own system of naming functions, and they pick whatever makes the most sense to them.

However, sometimes the choice is more systematic. You gave the example of a choice between OnInput, ProcessInput, and HandleInput. If the input function is the kind that is called only when something like a keypress has taken place, OnInput would be a better name. If the function is called each frame and checks to see if an event has occurred, then both ProcessInput or HandleInput would work.

Also, the choice could depend on the context. Say your render function is called OnPaint. In this case, calling the input function OnInput would lead to better overall organization than if you called it ProcessInput.

It's a self-documenting thing; prefixing it with "On" is an implicit contract with other modules that "this is an event," and can be trusted to be over with relatively quickly and should be called frequently.

Like AcePilot says, a function that's like "ProcessInput" may be ambiguous about its usage; do I call it once per frame or whenever I have new input?