What naming conventions do you use for your game's variables?

[Draconis (Daniel Stelzer)]

@jkj_yuio

I claimed it sucked because embedding a type into a variable name in a strictly typed language (what we were using at the time), was simply retarded.

Please don’t use this terminology.

[JoshGrams]

@Mike_G

@JoshGrams

A number of problems arise with this practice: a quantity may not have any significant properties, or it may have so many that it is difficult to remember which one was chosen.

In all my years of software development, I can’t say I’ve ever run into that scenario and I’m sceptical it is a valid concern.

Ah, I probably didn’t give enough context for that sentence: that was talking about being consistent in your naming, and the problems you might run into in coming up with rules that let everybody be consistent in the same way without having to guess, or getting it wrong regularly. Do you call it revoke or revert or repeal or rescind or abrogate or overturn? Pick one and stick to it.

Maybe that’s a bad example. Is it more important that it’s an open-end wrench, or a stainless-steel wrench, or a Stanley-brand wrench? Have a convention (for a given project, at least) about which you’re going to use for the name, so that someone can look at the thing and be able to predict the variable name without guessing. That kind of thing.

I can’t say I’ve really had the opposite problem where it’s hard to find any qualities to name a value after. Though I guess maybe some temporary in-between values have that problem. I feel like that’s usually a code smell though: a symptom that you’re trying to name the wrong thing and maybe you should break up the problem differently?

[Mike_G (Mike)]

@JoshGrams

Ah, I probably didn’t give enough context for that sentence: that was talking about being consistent in your naming, and the problems you might run into in coming up with rules that let everybody be consistent in the same way without having to guess, or getting it wrong regularly. Do you call it revoke or revert or repeal or rescind or abrogate or overturn? Pick one and stick to it.

Thanks, that makes more sense. My opinion is that rigid consistency is less important than naming which conveys the information you need for the particular bit of code at hand. Being wildly inconsistent is to be avoided, but trying to create a scheme which prevents even slight variations is probably not worth it.

@JoshGrams

Maybe that’s a bad example. Is it more important that it’s an open-end wrench, or a stainless-steel wrench, or a Stanley-brand wrench? Have a convention (for a given project, at least) about which you’re going to use for the name, so that someone can look at the thing and be able to predict the variable name without guessing. That kind of thing.

This is a good example of the kind where I mentioned refactoring being important. The absolute identity of the object and all its properties are less important to naming than a description of the thing that is of value for the piece of code at hand. If you have giant blocks of code where a single variable is being used in lots of different ways and depending on many properties of the thing held by the variable, then your code needs to be restructured into more specific pieces, i.e. functions, classes, modules, whatever. This prevents the “stainless-steel left-handed wrench with a rubber handle belonging to Bob” variable naming problem. This also resolves much of the need to have a globally acceptable naming scheme.

@JoshGrams

I can’t say I’ve really had the opposite problem where it’s hard to find any qualities to name a value after. Though I guess maybe some temporary in-between values have that problem. I feel like that’s usually a code smell though: a symptom that you’re trying to name the wrong thing and maybe you should break up the problem differently?

I agree completely.

[aidtopia]

I’d not heard of that split. It isn’t super clear what “kind” means in this context if not the type.

Joel Spolsky has an old blog post about the value of Hungarian Notation that talks a bit about how it fractured into the Apps and Systems styles.

[Mike_G (Mike)]

That was a good read. I see it was posted in 2005. I used to read Joel’s blog occasionally but it has been quite some time, so it was cool to revisit.

My observation after reading it is that (unsurprisingly) Systems Hungarian is pretty much useless, but also that I believe Apps Hungarian is a code smell: Primitive obsession. In a language with a good type system, using simple wrapper types instead of primitives to represent multiple kinds of things solves the problems Hungarian Notation attempts to solve, but in a far better way. Using variable naming to indicate different kinds of data can help a programmer catch mistakes, but wrapper types let the compiler do it infallibly. In Joel’s encoded string example, creating an EncodedString wrapper type and changing the application to only write out that type, solves the problem without relying on a developer noticing naming convention violations.

[twip]

Bumped into a youtube channel in another thread:

The first thing you need to understand about Inform is

I played a bit with Inform7 years ago. The only thing I remember experiencing was the disorientation of believing I could type in English (almost any logical sentence) and Inform would parse (the irony is not lost on me) the sentences and construct the logic behind the scenes. Then I became aware of what was really happening and was a little disappointed. (Also, I’m not saying the following to be argumentative in any way.) Regarding self-documentation, watch this short 5 minute video… …

There’s a pretty good one there about Naming Things:

Naming Things in Code

I wanted to share it, because I think it speaks directly to the conversation about what we mean when we say things like Type or Kind (or Unit).

They’re distinct.

[pbparjeter]

I consider myself a non-programmer and I assume nobody is reading my code.

Usually I use words that are unlikely to overlap with anything else in the text and code, which makes my variables easy to search for. I don’t need the variable to tell me what it means…I know what I’ve done and I need to find it based on a memorable word.

Not sure if this counts as a variable but I just looked at my Bigfoot Bluff code and saw that I made some clothing “sticky” which means you can’t take it off. There are probably more literal words you could use but I didn’t want to, and I knew nothing else in the game would be sticky.

I guess I’d change my approach if I was asking testers to read my code. If I have asked you to read my code…sorry?

[Hidnook]

Like the Curse of Binding enchantment in Minecraft (can’t take it off unless you die)?

[pbparjeter]

Hmm…I never really played Minecraft but it was more to have certain clothes go “out of sight, out of mind” once worn. It saved players from worrying about realistic layering of clothes and saved me from trying to implement that.

Not so much about affecting the player’s status, if that’s what you’re getting at.

Naming it was a different issue, and as you can see, the name I gave it doesn’t really describe it.

[inventor200 (Joey (Jess) Tanden)]

@pbparjeter

I don’t need the variable to tell me what it means…I know what I’ve done

Daaaaang, look at this dev over here, with a brain that successfully remembers how all the components of their project work! (lighthearted)

I regularly need to write my code like a brand-new team member is about to get a crash-course in it before writing commits, because that’s just me a few weeks into the future, still working on the same project.

Mental illness has not stopped me from coding but I certainly have to find ways to accommodate my future self, just to keep the project moving and intact.

Before I figured out proper project and code organization, I used to lose weeks of work in unrecoverable projects because I circled back around to a previous component and suddenly didn’t know what was going on anymore, and I foolishly left no comments for myself, and none of my variable/function names made any sense.

[Pebblerubble (Peter Wiehe)]

@inventor200

Before I figured out proper project and code organization, I used to lose weeks of work in unrecoverable projects because I circled back around to a previous component and suddenly didn’t know what was going on anymore, and I foolishly left no comments for myself, and none of my variable/function names made any sense.

Same here, too. I need good variable names, not too complex/big algorithms, comments, and a readme. Also I learned the hard way that using git is important (or whatever your personal VCS tool is).

[Mike_G (Mike)]

@inventor200

I certainly have to find ways to accommodate my future self

Meticulous naming, commenting and structure are what I do to prevent future me from sending a time-travelling cyborg assassin in search of present me.

[Draconis (Daniel Stelzer)]

Now that I’m doing more Dialog again, I’ve had to come up with some conventions for that. The rule used in the documentation is that predicates (functions, more or less) and constants are all in lowercase, while variables are in PascalCase, so I’ve tried to follow this.

Which means I need to name all my predicates to avoid using proper nouns in them, because it just looks wrong otherwise—“Hughes mood” becomes “inspector mood”. (I can live with the object itself being named #hughes.)

Beyond that, my conventions have changed a lot as I work on this project, but seem to have converged on: objects are named with no separation between words, unless one word is abbreviated to one or two letters. So the library door is #libdoor and the recycling bin is #recyclebin, but the top of the stairs is #t-stairs and the northeast garden bed is #garden-ne.

[ClaudioDaffra]

When I program in C, I use Hungarian notation and make names meaningful. However, for your question :

• Use descriptive names: Variable names should be descriptive and reflect the purpose of the variable. For example, playerScore or enemyHealth .
• Use camelCase: In many programming languages, it is common to use camelCase for variable names. For example, numberOfLives .
• Start with a lowercase letter: Variable names should start with a lowercase letter. For example, gameOver .
• Avoid using numbers at the beginning: You should not start variable names with numbers. For example, 3rdPlayer is not a good name for a variable.
• Avoid using reserved words: Avoid using reserved words from your programming language as variable names.
• Use consistent variable names: Try to be consistent with your variable names. If you use playerScore for the player’s score, then use enemyScore for the enemy’s score, not scoreOfEnemy .
• Use meaningful and descriptive names: This will make your code easier to understand for you and other developers.
• Use short and concise names: You don’t want to use long, unwieldy names for your variables. However, you also don’t want to use names that are so short that they are meaningless.
• Use consistent naming conventions: This will make your code more readable and easier to maintain.
• Consider using a naming convention tool: There are many naming convention tools available that can help you to choose consistent and meaningful names for your variables.

Remember, the key is to make your code as readable as possible for you and other developers. I hope these tips are helpful!

[pbparjeter]

Daaaaang, look at this dev over here, with a brain that successfully remembers how all the components of their project work! (lighthearted)

My games usually don’t have a lot of moving parts so it’s manageable even if I structure it poorly on top of everything else. It probably looks bad to a lot of people. I think the word is ‘spaghetti code.’

My Bigfoot Bluff code is the only one I cleaned up for testers IIRC.

[aidtopia]

@ClaudioDaffra

Use camelCase: In many programming languages, it is common to use camelCase for variable names. For example, numberOfLives .

More specifically, that’s dromedaryCase as opposed to BacktrianCase. ;-D

[ClaudioDaffra]

Thanks for the note! It makes things clearer. . It’s interesting to know that camelCase is also called dromedaryCase and PascalCase is known as BactrianCase.

[pbparjeter]

More specifically, that’s dromedaryCase as opposed to BacktrianCase. ;-D

I had no idea these terms existed. Weirdly it works based on whether the first word is a proper noun, too, not just the number of humps.

[Alianora_La_Canta]

I use BactrianCase combined with a lot of commenting. I find trying to type/kind-encode variables completely ineffective as a means of remembering what a variable does. With comments, I can handle even ridiculous variables (“Location”, anyone? For anyone curious, it was a variable used to make the advice system work in Budacanta, as it would remember where to take the player after the advice was dispensed according to location).

[SomeOne2 (Max Fog)]

Hmmmm, I’m surprised I’ve never commented here before, but since ZIL code is in all-caps (except for strings of text), my variables look something like ,CHECKED-ALIEN?
Though my newest WIP is about half the size of Milliways so far, and lot lot smaller in gameplay - but I’ve already exceeded the maximum limit of global variables by a lot, which I never encountered Milliways, which says something. It’s got variables like:

,FINISHED-BOTH-PLAYER-RUN
,RUNNING-THROUGH-ALL
,JUST-STARTED-AND-I-DONT-CARE
,FAKE-UNDO-SAVE
,OTHER-FAKE-UNDO-SAVE

(These all really in my game. There are longer ones as well… )