ECS naming conventions?

Hey guys, was wondering what everyone was doing regarding naming conventions for ECS stuff. For example, I'm still debating on appending "xxxComponent", "xxxSystem", "xxxJob" to their names, since it sometimes make them longer than I'd like, or perhaps abbreviate it to "xxxComp" and such.

Say for example if you have a DTO ScriptableObject called "HexTile" and you also have a component that represents the same thing in ECS, would you prefer calling the component "HexTileComponent" and the SO class "HexTile" or perhaps invert it and call the SO "HexTileModel" and the component "HexTile", since for most of the codebase it's the component that will be used the most. I know it's probably a bit subjective but I just wanted to see what people might think regarding naming conventions in ECS in general.

 

I was appending those naming conventions too for a while, but I was annoyed by it as it's kinda "hey look, its a VW Car", but everyone knows that VW is a damn car. (sorry for the commercial).

I ended up getting rid of appending but rather make more use of namespaces, because that's exactly what they are here for.

namespace MyGame.ECS.Components
{

}

namespace MyGame.ECS.Systems
{

}

 

I drive VW car and it's cool car

 

I don't see the need to attach post-fix, because when you're writing or modifying them you know what they are.
When you use them, entities and components are nouns (Player, Health, whatever), systems and jobs are verbs (Injure, ItemSort, etc).
You really can't use any of these out of their context (at least it should be super-rare), so I don't see the need of a separation. (You see them the entity debugger, you see systems in the systems list, entities in the entities list)

I prefer namespace to be more descriptive, it should encapsulate parts of the application (logical group), not type of things.

 

Never wanted to imply that it's a bad car

 

Postfix is as unnecessary as Hungarian notation. We have modern tools to let us know what all variables and definitions are anyway. Code is colour-highlighted to make easy, hovering over anything gives you the actual meaning (and documentation, if you bothered to comment properly). Let's extend the lifetimes of our keyboards a tiny bit by keeping names short

Namespaces are your friends.

Just bad management

 

While this is true in editor, and I do try attaching summary, in contrast,
looking at the code for example in github, or posting on the forum, this will not work.
Also, if you got many variables as an example, that become tedious, to check each description.

Personally I like to add meaningful wording, and / or prefix/postifx, so variable is descriptive as possible.
Even at cost of longer naming.
Useful, when aiming for implementing modding.
This days is not an issue. We are not limited to DOS naming constrains. We got access to auto completion in the end.

But for example, (my personal preference) if my names is xyz, instead writing at the end, or front, that it is native array, I just put prefix na_, or if is int i_, or float f_.
When coming back into code some time later, Without looking at variable description, I know that for example i_health is int, or i3_position (int3) etc.
I know data type, when required, without needing reading full variable name.

 

Namespaces are your friend for kindergarten projects or small stuff like the ECS demos. On complex projects where mass of variables to calculate and used under several conditions.. every prefix will save your company time and money and headache. Simply friends don't do this.

 

I didn't mean that pre/postfixing is bad, but unnecessary repetition is. Namespaces are a nice way to avoid "naming" your classes xxxHandler, xxxData etc- over and over again.

So for example when I have:

namespace MyGame.Handler
{
class World {};
class Items {};
}

namespace MyGame.Data
{
class World {};
class Items {};
}

I would also have the same folder/filename structure as above, but still instantiate them postfixed with

Handler.World worldHandler = new Handler.World();
Data.World worldData = new Data.World();

Important is to not include the complete namespace paths vica verca to avoid ambiguous collisions at all.