ID:121045
 
Be sure to check out:
Programming Tips #1 - If Statements
Programming Tips #2 - Making Progress
Programming Tips #3 - Design
Programming Tips #4 - Datums
Programming Tips #5 - Organization
Programming Tips #6 - Procs & Organizing Code
Programming Tips #7 - Comments and Whitespace
Programming Tips #8 - Loops and Ifs
Programming Tips #9 - The Map Editor


When you first start programming, the problem you're trying to solve is "how do I write code that'll do ______?". Initially you're happy just to get something working, who cares what the code looks like. But when you try to develop a complete game this indifference can become a problem. As your code gets messier and messier, the project becomes harder to work on - you're more likely to write code that has bugs and they become harder to track down and fix. Eventually it'll get to the point where you're wasting a lot of time, don't feel productive, and are more likely to stop working on the project.

As a more experienced programmer, instead of asking "how do I do ______?", you should start asking "what's the best way to do ______?". In this post we'll look at some rules you can use when naming vars and procs.


In a previous article I mentioned naming conventions. The idea is that variable names, proc names, and type paths are easier to remember if you consistently use a set of rules when naming these things. This article provides some examples of good rules to use when naming variables and procs.

These rules only really apply to global things, not to local variables. It doesn't matter if you call a local variable "m" because its scope is so small and its purpose is clear because you're only ever looking at that variable inside of its small context. You're always within a few lines of a local variable's definition so the name isn't nearly as important, but global variables or vars attached to objects can be referenced anywhere in your code so their names are much more important.

Don't use abbreviations.

Using a naming convention is a way to exploit consistency. Abbreviations breed inconsistency. If you're making an RPG where the player kills enemies and gains experience, you'll have many variables and procs that deal with experience:
  • a variable to store the player's current experience value
  • a variable to store the experience value needed to level up
  • a variable to represent how much experience an enemy awards
  • a proc to increase the player's experience value
Using abbreviations gives you more opportunities to be inconsistent. These vars and procs might end up looking like this:

mob
var
experience = 0
xp_to_level = 100

proc
gain_exp(xp)
experience += xp

enemy
var
exp_gain = 10

If you use a mix of the terms xp, exp, and experience, you have to remember which term was used in each place. If you avoid abbreviations entirely you'll easily know that the enemy's experience value is called experience_gain, not xp_gain or exp_gain.

Use names that are just descriptive enough.

Using names that are overly descriptive is another way to create inconsistencies. The longer and more descriptive a variable's name is, the more likely it is that you won't consistently describe it the same way.

Use positive forms for boolean variables.

If you need a variable to determine if each mob is ready for the game to start, call it "ready" instead of "not_ready". Having things like !not_ready in conditional statements will trip you up and this is completely avoidable.

If you do want the variable to be 0 when the player is ready, just use a different term instead of "ready". For example, call the var "idle" and check !idle to see if the player is ready.

Use prefixes sparingly.

Prefixes might seem neat and useful but they're often not. If you try to use them widely you'll end up getting annoyed with them and will have trouble using them consistently. Don't treat them as prefixes that have to be globally applied, just think of them as part of the variable's name and use them only when it makes sense.

Objects are nouns, procs are verbs.

This isn't something you have to follow strictly, but it's a good idea that can help you think of names. A proc is an action so its name should reflect the action it's performing. An object is a thing so its type path should be a noun.


The purpose behind these rules is to improve consistency to make names easier to remember. You don't have to follow these rules all the time, but you should be aware of the benefits that having rules can create.

Look at your own projects and see how you name things. You probably follow some patterns even if you never thought of it that way. See what rules you follow and look for cases where you're not consistent. Find your own set of rules and keep them in mind from the very start of a project.
Yeah. Names like that are so much easier than what I've done in the past. I remember I used PP as a variable and it didn't stand for anything or things like warmorp. It's so much easier to actually write out what they are so you understand it better and make things simple for yourself.
Generally I use short-hand variables inside of loops and for generic things like "var/savefile/F", but if I intend to use the variable more than once or twice (especially a bit away from where I defined it) I'll name it something more descriptive.
I focused on global or member variables because their names are more important than local variables, but they should probably get more of a mention.

I tend to use the first letter of the object name for local variables (var/mob/m, var/obj/o, etc.). I also tend to use i or n as generic numbers: for(var/i = 1 to 10), or i, j, and k if there are nested loops. Though, if the variable has some more specific meaning I might name it differently: for(var/x = 1 to world.maxx).

One one hand it's not as important to name local variables decently because you can always look back to the definition to see what things are called. But on the other hand using inconsistent names there can easily cause problems and it can really improve code if you don't just use arbitrary letters.
There's something I see you do in your libraries that I'm curious about.
datum
var
X
_X

loop()
if(X != _X)
X_HAS_CHANGED()
X = _X

I'm wondering how practical this is, since I've never seen it used before. I understand what it does, but when is it appropriate?
Kaiochao wrote:
There's something I see you do in your libraries that I'm curious about.
> datum
> var
> X
> _X
>
> loop()
> if(X != _X)
> X_HAS_CHANGED()
> X = _X
>

I'm wondering how practical this is, since I've never seen it used before. I understand what it does, but when is it appropriate?

I try to use it only when a loop will already exist in which I can check to see if the value changed. Otherwise its probably not that practical.

I sometimes don't want to force people to use procs to set vars. I think i only did this in the dynamic lighting library though.

datum
var
X
_X

loop()
if(X != _X)
X_HAS_CHANGED()
X = _X