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
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.