What is a good naming convention for script components?

Hi all,

I've googled my question in different ways first, and couldn't find good recommendations/examples to learn from. Now, I know this is a matter of taste and is subjective, and that's why I'm posting here and not on answers website.

The basic problem is that I struggle with finding good names for my C# classes (scripts) that are components, while trying to follow good C# naming conventions.

I'll give an example from the game I'm working on: I currently have a tank game object with a Tank C# script component, and I want to split the tank script to multiple components, so the said game object will contain them. This tank can move, shoot, has health and use special abilities, so I thought of making 3 scripts. AFAIK, C# classes names shouldn't be verbs, only nouns. So:

• "Movement" (for going forward, backward or rotation) sounds OK. It is a general noun that represents an idea, an ability that a tank has. It isn't "Move".
• "Health" is also good.
• "Fire" doesn't really represent the tank's ability to fire or shoot. I thought about "Firing" but it sounds weird.
• "Ability" sounds like an object class that represents the ability itself, which is also a problem because I already have that exact class. I'm trying to find a good name for a component class that represents the idea of a tank having a special ability, e.g: "AbilityHolder" - but that sounds bad too.

If you could give me examples from your projects, or a general idea of how you name your component classes, that would be great.

 

A good component naming convention is anything that follows the semantics of your use case, a useful mnemonic that is also a reflection on the intended abstract usage, and more or less follows the rest of the naming principles in Unity.

A good general convention, such as the one recommended by Microsoft, is whatever is intuitive for the people working in the industry at large, where employees may shift between different projects, and may even switch the companies, and where many project codebases typically have to last a decade or more. In such circumstances, a poor general naming convention would mean more lost time, or less understanding of the system, which translates to an economic inefficiency in the long run.

Outside the aesthetic need to have somewhat compatible nomenclature between the existing APIs and system libraries, one guy working on a pet project absolutely should not mix the two concepts. In other words, you're overthinking this.

 

Sometimes, I'll call things a "BlahController", if there isn't a convenient noun available. If the script instead manages many objects, it'll be a "BlahManager". That's a matter of taste though, I'm sure there's a Ted talk out there somewhere saying I'm the Worst Developer Ever because of this.

 

@WallaceT_MFM I do the same, I just checked and my project is riddled with *Controller and *Manager . To simply put, if it's a monobehaviour for a single objects, I call it whatever that object is +Controller, or if it controls several *Manager.
For example, ChatRowController, ChatManager. Since I work a lot with UI, I also use for example ChatDialogController.

However, it's important to have a common sense limit to it, so don't go crazy on doing something like MyGameCanvasChatDialogController. In such cases go with namespaces in the code. And remember you can have multiple scripts with the same name if you use namespace.

Code (CSharp):

1. namespace MyGame
2. {
3.      public class ChatDialogController: MonoBehaviour{
4. {
5. ...
6. }
7.  
8. }

 

I get it, but maybe it's better to ask how to name a particular thing, than to ask about a naming convention in general. There is no naming convention, you are likely to get an empty discussion about tastes, industry standards, and things that you could've found out on Google, just by browsing around and looking other people's code.

Programming nomenclature in general has to do with the following three things (I've been around)
- level of expertise / i.e. beginner vs pro, comes with lots of experience
- domain of expertise / i.e. finances vs astronomy, each domain with their own perks and terminology
- trends / i.e. being a social drone vs being hardcore pragmatic, each end with its own pros and cons

And finally, some people are just bad with names. All kinds of names, words... Lexical creativity.
In the end, you just want something that works. And makes sense.

 

Honestly... I don't know exactly what pattern I follow. I just name my things. Not sure if they make sense to most people. I think they do, but who knows.

For example, here's several components in one of my projects:


All my scripts appear to generally be *AssociatedEntityType*SpecificAdjectives*Type*. With some exceptions of course.

Entity - represents the root of an entity and associates all components/child components as a whole entity.
Brain - it's the primary ai script
Logic - logical components that integrate with Brains
Animator - script that is accessed to animate the entity (abstracts the calling of an animation from the actual animation type: Animator/Legacy/Procedural)
Anim - a script that performs a procedural animation as opposed to a standard Unity Anim.
State - defines a behavioral state of an entity (AI logic transitions entities between states, player input transitions the player between states)
Style - behavioural style of an entity. Could be a movement style, an attack style, etc
Motor - movement controller, a movement style will access a movement motor to actually move the entity (movement may be walking/jumping/interacting/etc)
Controller - logistical controller for a simple system. For example a PushRigidbodyController facilitates the actual physics calculations when the player interacts against a moveable rigidbody.
Weapon - a weapon

There are other naming conventions though. This one:


This is our "event modeling system" also called our "T & I system" by my artist/designer/partner.

The general thing is T's trigger things, I's get triggered. It's sort of like UnityEvent, but predates UnityEvent, and supports just generically triggering without having to specifically wire up which method gets called.

Why T? T is for trigger.

Why I? Well... this is really dumb, but my partner likes it. It's because I_PauseScene, well "I Pause The Scene". Where I is the script... My partner thinks of it like "Hey script, what do you do?"... "Well person, I Manipulate Doors."

Personally I hated it. But since these are little components that can be wired together like a visual code editor. They made sense to him. I only write them... he has to deal with wiring them together. So it's only fitting the naming convention benefits him and not me.

 

Thanks guys for all of your answers. I see now that my question may have been too broad. I didn't meant to ask a too-general question and I know that naming conventions in programming are a matter of taste.

I was mostly looking for specific examples from your projects, it always helps me make a good decision. @WallaceT_MFM and @FernandoHC, "manager" and "controller" can be good sometimes. You gave me a nice idea for my case, so thanks. @lordofduct that's an awesome way of handling your script names. Personally I have much, much fewer scripts so this way is an overkill for me, but as I said, it's always good to see others projects.

Maybe I am overthinking this, at least now where my project is really small.

 

I got in the habit, from trying to do things the "Unity way" of using postfix

script

on monobehaviours. Similar I think to how Fernando says them Controllers. If I see

OrcScript q;

I know that q.gameObject and so on is legal, and it probably contained a function for anything I want to tell that orc.

I generally have component type scripts as stand-alone classes. The orc might create a health instance, but it won't be a monobehavior. But I think for component scripts, I use postfix "Part". So

attackPartScript aps;

lets me know it's on a gameObject, which probably has a

monsterScript

on it.

For no reason, LordOfDuct's "Entity" is for me adding "Base" at the end.

BoxBase b1;

lets me know it has general info about this box, but

BoxScript

's on child objects are doing the real work.

 

_S - All components have S (for 'Script') at the end. Usually modular, not coupled to anything else.
_ManagerS - Usually a singleton or a component of which there is only one.
_ControllerS - Something that knows a references a lot of other components. Probably has an FSM to control what components are enabled.
GUI_S - A script for UI components.
_Data - For ScriptableObjects that are there as data (ItemData).
Player_S - Sometimes for player-only components.

Example:

Code (csharp):

1. public class PlayerControllerS : MonoBehaviour {
2.  
3.     [Header("References")]
4.     private HealthS _healthS;
5.     private EquipmentS _equipmentS;
6.     private InventoryS _inventoryS;
7.     private MovementS _movementS;
8.     private AbilitiesS _abilities;
9.  
10. }

 

You will also develop a sense of how to group and name things, which part should come first for sorting, etc., as you work with more and more types and varieties of scripts.

A lot of it comes down to how you retrieve ideas from your brain. When you think "I need the Lizard Weapon," do you regularly come at that first from the weapon point of view and you're looking for a lizard who can hold it, or is it the other way around?

For different classes of scripts in your project, you may find it works better to prefix or suffix with various things, such as category, or type, or name, etc.

And don't be afraid to refactor; it is SOFT-ware after all... as long as you're consistent enough to aid you in finding and thinking about problems you encounter.

And barring any of that, you can always fall back and name your classes A, B, C, D, etc.

 

I actually love that. Feels really intuitive.