Naming convention of functions that are a "response" to events.

Unity Engine
1

If i’m not mistaken the convention is to [delegate] + EventHandler suffix.

So if in a class we have:

public UnityEvent ButtonPressed;

private void OnButtonPressed () {
     ButtonPressed.Invoke ();
}

Then the response, in another class, should be:

public void buttonPressEventHandler () {
     Debug.Log ("OMG!");
}

But if we use the inspector to “reference” that response to our event. What the editor reflects is:

ButtonPressed → OtherObject.buttonPressEventHandler

Doesn’t it feel like there could be a better understanding on the “functionality” if i would actually name the response in relation to what it does? I could see something like:

ButtonPressed → OtherObject.logOMG!

How do you do, naming? :smile:

2

Names matter nothing at all to code, all its used for is for us as programmers to know what a function does. I cant imagine a function with the only purpose to output a Debug string. I sometimes have long function names because I want them to be descriptive, but as long as you (and the people working with you) understand what the function does by its name or whatever you are good to go.

3

That’s the point, at the moment we take advantage of the inspector to reference event responses i noticed that this naming convention is not very useful at all.

Even the class “readability” of the “listener” get’s a little worse by naming a function [delegate] + EventHandler suffix.

public class SceneController () : MonoBehaviour {
    public void ButtonPressedEventHandler {
         // Change scene code.
    }
}

VS

public class SceneController () : MonoBehaviour {
    public void ChangeScene {
         // Change scene code.
    }
}

In inspector it also improves:

ButtonPressed → SceneController.ButtonPressedEventHandler

VS

ButtonPressed → SceneController.ChangeScene

4

There is no set naming convention that you HAVE to use, i’m not quite sure what you are talking about.
There is no obligation to do anything,you could name functions with numbers (wouldn’t compile but you get the point).
Most coding conventions that people use are just set by the company or personal standards/preference. There is no actual reason why we capitalize public variables and use camel casing either for that matter.

When you make an interface or abstract class I usually prefix them with an IData or AEnemy if I use them, its just for convenience and doesnt actually serve any real purpose.

5

I didn’t read that it was actually a convention for X++, sorry.

But I created this post not to read that a convention doesn’t need to be followed but to rather discuss which naming strategy for events and listeners could be better within Unity environment. To improve my naming strategy.

From what you said i get:

  • Better to prioritize description than length.

  • Depends on company standards / preference.

So, common standards? common preferences? examples? :stuck_out_tongue:

6

Adding eventHandler to the name is to make hand-writing code simpler. When you’re writing button1.initialize(…) it’s easier to find and see the handler functions. But you’re describing a visual process using the GUI, right? No more searching function names, so no need for a long EventHandler suffix. Useful conventions are based on the exact process you use to make code, and change with them.

An old style is something like _EH, for things you only sometimes need a reminder for. logOmg is just fine, since that’s what it does. But some eventHandlers get the name of who sent them and so on. logOmg_EH would be a reminder why it has those extra ignored parms.