Best variable naming conventions?

E

elsi11

Guest
Hey guys!

I came to a point where I decided it would be cool to just pick some rules on how to write my variable names. Sometimes I separate words with underscores, but then end up using a capital letter for X or Y. I never liked capital letters and camel cases because the readability is meh, and shift is further away than an underscore. At one point, I decided to put a prefix on my local variables because I use a whole bunch of them all the time because I think I'm cool when I make a script, and you just fill it up with some info. And just today, I realized that an underscore as a prefix is nice looking, until you use it in a script, and it doesn't play nice with commas.
Also, I sometimes used reserved names like direction or dir, and object variable names like state for my enums, and I was told that was super bad (even though everything worked).

So I dunno. Is there some kind of special naming convention you guys use? I read the wiki about conventions and it said this joke:
Variable names should not start with underscore (_) or dollar sign ($) characters, even though both are allowed. This is in contrast to other coding conventions that state that underscores should be used to prefix all instance variables.
So, yea, didn't learn much from that.

What do you use? What should I use?
:)
 

Yal

🐧 *penguin noises*
GMC Elder
Here's some stuff I use:
  • Constants have a prefix that demotes their type and then an unique second part, e.g. for character names char_MATT and char_PAIGE. I find lowercase letters to be easier to read overall, but most people make their constants uppercase, so I just picked a compromise.
  • The further the "distance" between a variable's declaration and use, the longer and more descriptive its name should be. For loop counters, I more or less exclusively use single letters (starting at c and then incrementally using later letters for each level of the loop - because I giggle a bit whenever I type c++), and if a variable only changes a single thing in a very specific case, it can get a longer name like triggered_train_brake_event. For object variables, I usually use succinct stuff like menuvalue, state, cntr. For input, I usually use stuff like k_a, k_st for key states, since "k" is pronounced "key" and I usually use these in hundreds of places in a big project.
  • Generally variable names should be actual, full words if possible - I've had several cases where I couldn't tell what my variables did anymore because I'd forgotten the mnemonics. Only shorten stuff if a part becomes redundant, especially when overused (like the k_ variables above).
  • Name variables hierarchically, with the most significant part first (e.g. k_* for keys, char_* for character traits, ai_* for AI, and so on). This makes it easier to search for related stuff.
  • I only use underscores to separate hierarchic bits (e.g. ai_aggressionradius instead of ai_aggression_radius), not every word. I guess that's a taste thing when it comes to readability.
  • Global variables already are prefixed with "global.", so no need to prefix them with a special global prefix.
  • GM doesn't have member or static variables, so no need to add extra prefices for that.
 
Z

zendraw

Guest
xx, yy, xxx, yyy, a, b, c, i, t,...any letter. dir, butt, cc, po, dis, len, ln, dr, st, mt, str,

u get the point. as long as you know what means what, and dont change a habbit, its fine. and no, butt is short for button.
 
E

elsi11

Guest
Ok, I'll make a decision now.

enums: FRUIT.BANANA
object variables: Banana
local variables: banana

Wait, does gamemaker differentiate between upper case and lowercase? Do other languages do it? I bet python and ruby don't...
Then, maybe.. a literal prefix for object variables because I use less of them than local variables:

object variables: o_banana
local variables: banana

Well, while we're at it, might as well, put a prefix on local variables to protect ourselves from them being reserved. Hell, might as well do it for everything:

enums: e_speed.BANANA
object variables: o_speed
local variables: l_speed

I don't like this....
 

JackTurbo

Member
yes variables are case sensitive, although the auto-suggest usually will catch it in gms2

As for what is best? - it doesnt really matter so long as you know what is going on. Consistency is more important than any specific conventions.

Personally I use:
_enumType.enum
script_name
MACRONAME
instanceVariable
localvariable
 
E

elsi11

Guest
Hmm.. Maybe just giving a prefix to enums would solve my problem with same-named non-reserved variables appearing red as if they are reserved.
example:
state.banana
state = state.banana
The object variable "state" will appear red because "state."is already an enum prefix. So the solution would be e_state.banana.
Ehh. Ain't nobody got time for writing prefixes. maybe just _state.banana and var _state. Are there no other special characters but "_" ?
 

Yal

🐧 *penguin noises*
GMC Elder
Wait, does gamemaker differentiate between upper case and lowercase? Do other languages do it? I bet python and ruby don't...
MOST languages do - it's usually easier to make a language case-sensitive since upper and lower case letters are different symbols under both ASCII and Unicode. GM does it, I'm pretty sure Python does it, and I've never used Ruby. It's still a bad idea to mix two variable names that only differ in casing, though - you will mix them up sooner or later :p
 

Yal

🐧 *penguin noises*
GMC Elder
Hmm.. Maybe just giving a prefix to enums would solve my problem with same-named non-reserved variables appearing red as if they are reserved.
example:
state.banana
state = state.banana
The object variable "state" will appear red because "state."is already an enum prefix. So the solution would be e_state.banana.
Ehh. Ain't nobody got time for writing prefixes. maybe just _state.banana and var _state. Are there no other special characters but "_" ?
Another idea is to affix your enums with a "t" (an abbreviation of 'type'), e.g. state_t.banana - no name collision, you clarify what is a type and what is not, and you put the burden of typing longer names on the thing you use the least often, namely the enum.
 
E

elsi11

Guest
Another idea is to affix your enums with a "t" (an abbreviation of 'type'), e.g. state_t.banana - no name collision, you clarify what is a type and what is not, and you put the burden of typing longer names on the thing you use the least often, namely the enum.
I love this solution :D
Any advice for object variables vs local variables? I want to differentiate them because it is important. But I would also like to lower the possibility of using a reserved variable for my object variables.
My current solutions are: state_t.banana, state, and var _state.
The problems are that the _underscore,_prefix,_looks, _confusing, _in, _scripts,
and that one might name the object variable a reserved name by mistake ( speed or direction)

Tnx! :)
 
H

Homunculus

Guest
I started using _varname too for local variables a while ago. It does solve a few headeaches imho. Since GMS2 though, local variables get a different color so I'm not so sure anymore about this naming convention...

Since we are on this topic, one thing I'd like to know as well is how you guys declare local variables (especially in scripts having lots of them). I generally declare everything on top of a script like

Code:
var _x, _y, _name, _color;
but sometimes I just find more convenient to declare them on first use like in

Code:
var _x = 0;
var _y = 0;
var _name = "Foo";
/* ...some code... */
var _color = "Bar"
I still can't figure out which method works better...
 
D

Destal

Guest
I use camelCase for ideas and underscores to separate ideas, it's a bit vague but it's something like this:
playerOne_lightAttack
playerOne_lightAttack_cooldown
playerOne_lightAttack_maxSize
playerTwo_heavyAttack_fireRate

I use this concept for variables, objects, scripts, etc. which gives:

Variables

Three different naming styles
var _lightAttack_delay (starts with an underscore)
playerOne_health_ (ends with an underscore)
global.time_oneSecond

Scripts
Starts with an action, then underscore, then informations
create_sentryEnemy
get_enemyStats
destroy_playerShip

Resources
s_playerOne_ship
ts_mountain
snd_pauseMusic
pth_sentinel
fnt_main
tl_arcadeMode
o_ship_destroyedState
r_level1_area5
 
D

Destal

Guest
I started using _varname too for local variables a while ago. It does solve a few headeaches imho. Since GMS2 though, local variables get a different color so I'm not so sure anymore about this naming convention...

Since we are on this topic, one thing I'd like to know as well is how you guys declare local variables (especially in scripts having lots of them). I generally declare everything on top of a script like

Code:
var _x, _y, _name, _color;
but sometimes I just find more convenient to declare them on first use like in

Code:
var _x = 0;
var _y = 0;
var _name = "Foo";
/* ...some code... */
var _color = "Bar"
I still can't figure out which method works better...

Some local variables are created from operations so I can't declare them ALL on top, so I declare them when I value them and use them.
 
B

Binary Orange Studios

Guest
This is the convention I use:

If it's global, it's capitalized LikeThis.

If it's local, it's camel-cased likeThis.

If it's a temporary variable (something returning from a function, for example), it might be written likeThis or this, where it's all lower-case.

I stay away from underscores because I find them difficult to type out!

Also, I sort of stole Unreal's naming conventions for booleans. bIsActive, for example.

I almost never use prefixes for variable names because usually the variables are only pertinent to that particular object/script. But, to each his own, and you should do whatever makes you most comfortable and what is most readable to you!
 
Z

zendraw

Guest
one thing id like to point out. you can use a singe temporary var as much as u want so long you reset it before using it. a simple example is 'i', when i have multiple loops in an event i simply set var i at the begining and then reset it to 0 before the loop. or to whatever value i need.
 
H

Homunculus

Guest
Some local variables are created from operations so I can't declare them ALL on top, so I declare them when I value them and use them.
What do you mean? You can definitely declare something like "var i" at the top and use that in for(i=0;...;...) {}
 
D

Destal

Guest
What do you mean? You can definitely declare something like "var i" at the top and use that in for(i=0;...;...) {}
Yes my bad, what I mean is I can't value them all on the top, and since I don't declare variables without valuing them (except of course if needed) then I don't declare them. I declare them in the scope I use them.
 

Hyomoto

Member
The real moral of this topic is the way I do it is right, and the way everyone else does it is wrong. However, I will offer a piece of advice you might actually find useful: with the exception of local variables, GM2 will remember every variable you've ever typed. Because of this, it can also be quite helpful to not just be descriptive with your variables but also "try not to reinvent the wheel" with each one. Otherwise you might end up staring at a list of variables:
walk_speed
walkSpeed
speedWalk
walkingSpeed
 

Maximiliano

Member
As said before, as long as you're consistent throughout your project you can use whatever naming convention you want.

I personally use underscores because it fits in well with the built-in variable and function names.
 

Hyomoto

Member
@11clock - I feel like that could make one hell of a game jam concept. It would be interesting to say the least. I don't know how you would enforce that rule, but you'd be, if nothing else, limited to the number of text message acronyms you know.

In my case that makes about five.
 

Joe Ellis

Member
I usually try and group scripts, and begin the name with whatever the function is associated with, like model_load, voxel_create_cell, triangle_get_flat_normal, skeleton_add_bone, shader_compile_draw_event, render_state_execute, render_target_create.
 
Top