GML Naming Scheme

samspade

Member
A random half-programming-half-design question - for those who use enums for states what naming scheme do you use?

My current scheme is [object]_state for the instance variable, where object is the object type - e.g. player_state, enemy_state, and then [object]_states (plural) for the enum. It works well for clearness, but can get a little wordy and sometimes the difference between the plural (for enum) and singular (for variable) can be missed.

example in use:

Code:
enum player_states {
    running,
    walking,
    jumping
}

player_state = player_states.running;
 
A random half-programming-half-design question - for those who use enums for states what naming scheme do you use?

My current scheme is [object]_state for the instance variable, where object is the object type - e.g. player_state, enemy_state, and then [object]_states (plural) for the enum. It works well for clearness, but can get a little wordy and sometimes the difference between the plural (for enum) and singular (for variable) can be missed.

example in use:

Code:
enum Pstates {
    Walk,
    Run,
    Jump
}

State = Pstates.Run;
Too much to easily type the wrong word the way you've shown above.

I'd shorten it to what I've wrote in the quote.

No point writing out player everytime if this is setup for the player object anyhow.

You could even write, W, R, J for walk run and jump so long as you know what it stands for.
Same for states. It can be any word. I tend to just write Move. So:

enum Move ... W,R,J.... State = Move.W; and so on.

End if the day, You type what works for You and what You understand. If you fear you may not understand it, type // w = walk, r = run and so on above the paragraph of code in your create step or right beside it. Use those // for anything to refer back to. They're extremely useful.

Hope this helps.
 

NightFrost

Member
My norm is Player_State for the enumerator and State_Current for the tracker variable. As the variable is instance scoped it doesn't need to explain itself further. When referred to elsewhere it would have some prefix like obj_player.State_Current which also is clear enough. Personally I don't mind wordiness in my enums and variables, and if they're long there's always the autocomplete.
 

dannyjenn

Member
Is there any real advantage to using enums over macros?

I personally have never gotten into the habit of using enums, and part of the reason is because I don't like the dot notation. Seems to add unnecessary verbiage to the code, which I too easily confuse with instance variables (e.g. I see player_states.walking in the code, and have to pause and ask myself, "Is player_states an enum, or is it an instance?").
Along those lines, I don't see much point in localizing things. Why use one enum player_states.walking for the player and another enum enemy_states.walking for the enemy when you can simply use the macro walking for both? Maybe the latter is considered bad style, but I generally prefer all my constants to be global like that. (Granted, it might get messy if you have several state machines and your naming scheme isn't very organized. I suppose the dot notation could be more useful there.)

But with regard to macros, I always do them in all caps (e.g. WALKING, as opposed to walking) so that I can easily (at a glance) distinguish my constants from variables. In cases where I need to make it clear to myself that WALKING is the name of a state rather than some other constant, I'll give it a more specific name like WALKING_STATE or perhaps STATE_WALKING. (In extreme circumstances I might need to go with a name like PLAYER_STATE_WALKING...)
 
Last edited:

Rob

Member
Is there any real advantage to using enums over macros?

I personally have never gotten into the habit of using enums, and part of the reason is because I don't like the dot notation. Seems to add unnecessary verbiage to the code, which I too easily confuse with instance variables (e.g. I see player_states.walking in the code, and have to pause and ask myself, "Is player_states an enum, or is it an instance?").
Along those lines, I don't see much point in localizing things. Why use one enum player_states.walking for the player and another enum enemy_states.walking for the enemy when you can simply use the macro walking for both? Maybe the latter is considered bad style, but I generally prefer all my constants to be global like that. (Granted, it might get messy if you have several state machines and your naming scheme isn't very organized. I suppose the dot notation could be more useful there.)

But with regard to macros, I always do them in all caps (e.g. WALKING, as opposed to walking) so that I can easily (at a glance) distinguish my constants from variables. In cases where I need to make it clear to myself that WALKING is the name of a state rather than some other constant, I'll give it a more specific name like WALKING_STATE or perhaps STATE_WALKING. (In extreme circumstances I might need to go with a name like PLAYER_STATE_WALKING...)
Regarding the confusion over whether something is an enum or not, this is why I use e_ before a enum so I know what it is. Apparently that's bad form for programmers but it works for me.
 

NightFrost

Member
Is there any real advantage to using enums over macros?
In this use case, as an array index, none really. Enums might have a slight convenience advantage in not having to write out the numbers, but otherwise it is a matter of preference. I'm used to thinking in enumerators when planning my code.

As for confusion, I strive for consistent naming schemes. I wouldn't have player_states as instance pointer name, and besides that it would be receiving the ID at some point in code. The meaning is generally implicit when you read the code from the beginning ("code is the comment" and all that). And there'd be comments too, at least in my code. Naming schemes are a matter of preference as well. I have used a combined states enum before for both player and enemy states, but decided separation is better, as there (usually) would be a number of states not shared between those entities.
 

samspade

Member
Is there any real advantage to using enums over macros?

I personally have never gotten into the habit of using enums, and part of the reason is because I don't like the dot notation. Seems to add unnecessary verbiage to the code, which I too easily confuse with instance variables (e.g. I see player_states.walking in the code, and have to pause and ask myself, "Is player_states an enum, or is it an instance?").
Along those lines, I don't see much point in localizing things. Why use one enum player_states.walking for the player and another enum enemy_states.walking for the enemy when you can simply use the macro walking for both? Maybe the latter is considered bad style, but I generally prefer all my constants to be global like that. (Granted, it might get messy if you have several state machines and your naming scheme isn't very organized. I suppose the dot notation could be more useful there.)

But with regard to macros, I always do them in all caps (e.g. WALKING, as opposed to walking) so that I can easily (at a glance) distinguish my constants from variables. In cases where I need to make it clear to myself that WALKING is the name of a state rather than some other constant, I'll give it a more specific name like WALKING_STATE or perhaps STATE_WALKING. (In extreme circumstances I might need to go with a name like PLAYER_STATE_WALKING...)
Everything an enum does you can technically do with a macro, but there are a few advantages to enums. The big one is automatic renumbering. Since they default to 0 and increase by one it means that you can just change enums and your arrays, lists, etc. all still work. With macro's, you'd have to go back through and manually change them. Conceptually, I also think the dot notation serves as a nice grouping. So I tend to use enums for things that work in gorups and macros for things that are by themselves or very general (e.g. I have the macro NONE -1 in almost all my projects).
 

TsukaYuriko

Q&A Spawn Camper
Forum Staff
Moderator
I use a combination of "everything that's a constant is in all caps" and "the scope is implied by common sense" here.

Code:
enum PLAYER_STATE
{
    RUNNING,
    WALKING,
    JUMPING,
};

state = PLAYER_STATE.RUNNING;


No need to call the variable player_state since it's already in the player object, so the context of it referring to PLAYER_STATE is implied. (I'd also be using the same name twice otherwise, just not all caps...)
This has the added benefit that the state variable has a uniform name across all objects, so there is no need to remember it and type it out every time. Ideally, this would let me use a script that literally sets state and takes care of any other potential operations I'd like to apply to any instance upon changing states. It's as close to inheritance of not only variables but also methods/functions as it gets with GML's current capabilities.

On the subject of not having to type out things all the time, for those of the "shorten variable names so you have to type less" mind set: I highly advise against shortening any descriptive names such as PLAYER_STATE. PSTATE could refer to just about anything that starts with P. Player, portal, plane, platypus...
On top of that, P L A Y ENTER requires less key strokes than typing out P S T A T E, but does not require me (or my collaborators) to memorize or look up which variables I shortened, and to what. So does P L A Y DOWN DOWN ENTER if you have multiple enums that start with PLAYER. Shortening stuff when it's impossible to figure out what it refers to by common sense when it pops up in auto-complete ("bgm" for example) is a stab in the back of the entire team, sans maybe yourself.

Why PLAYER_STATE and not PLAYER_STATES? For me, it's a matter of context and chosen quite deliberately in this case.
If I'm only ever going to use a collection in a scalar context, I use a singular name. A prime example of this is a state enum - whenever I use it, I'll either assign or check for one specific state.
If a collection is only useful when I have access to and use multiple or all of its elements, for example to iterate over it or to pass multiple values around, I use a plural name, such as for inventories, tiles...
 

Yal

GMC Memer
GMC Elder
I always use macros instead of enums... you can define them wherever you want, but they've got better syntax highlighting (especially in GMS1) and can have string values (and also the same values, which can be useful for things like coordinates/sizes and weighting factors). Heck, since they're fully text-replace just like C macros, you can have macros replace script calls and mathematical expressions dynamically too!

Scheme-wise, I have the following conventions:
  • Major constants are all-uppercase like normal people's conventions: TILESIZE, VIEW_W etc
  • Array indices start with a lowercase mnemonic and have an all-uppercase specifier: key_WALK, wd_MENUSPRITE. The idea here is that... uhh, I guess I thought it was easier to type/read lowercase letters and I mostly use autocomplete to fill these in? I don't really remember.
  • Actually I use the lower-uppercase combination for a lot of stuff other than array indices too.
 
Top