Consider the following code snippet:

  class GameObjectClass
  { 
    char      name[64];
    vector3f  position;  // where the object is
    matrix3x3 rotation;  // how that object is facing
    int       strength;
    int       dexterity;
    ...
  }; 

Looks fairly typical of what you might see in a 3D application. What could be wrong with this? Yet, ask somebody to describe the earth's rotation. They are not going to say the sun is in that direction and Venus is over there. Instead they will probably say, the Earth turns once per day about an axis going through the north and south poles. In the English language, the word rotation usually refers to spin or angular momentum. With this in mind, look again at the code snippet. Notice the placement of 'rotation' right next to position, the lack of a linear velocity member, the type of the variable, and comment following. Clearly, the member 'rotation' is actually referring to the object's orientation.

It is true that the orientation is described as a 'rotation relative to the identity orientation'. In other words, orientation is implemented as a 3x3, upper-left 3x3 of a 4x4, or (most often) as a quaternion. Trying to use this piece of data in any meaningful way can only be done by applying a rotation - i.e. rotating something. But what this is really suggesting is that rotation has more to do with the 'type' of the member variable, not the 'name' of that member. By the same false reasoning that uses 'rotation' instead of 'orientation', the class member 'position' should be changed to 'translation' to be consistent (yuck). In this context, most developers would prefer to describe a game object's pose as position and orientation.

Beware; the dagger of terminology misuse is sharp on both sides. Observe how the inconsistent usage of the term 'rotation' now affect further game development as we try to add additional physics members (angular properties) to our game object class. Fortunately, angular velocity has a non-ambiguous non-verbose term: 'spin'. So use that. The trouble now with adding a member called 'rotation' to describe angular momentum (btw it's not the same thing as spin) is that others are likely to misinterpret it and assume it means orientation. Isn't name pollution wonderful? Consequently, we're stuck using a verbose member name such as "angular_momentum" or some sort of shorthand like "ang_mntm". Groan.

Im am not suggesting that the term 'rotation' should never be used in code again. There are examples where it is clearly the best word and there is no ambiguity. If you have a generic function in your linear algebra math library (not at the game object level) that decomposes a matrix into its affine parts then it makes sense to use the term rotation. In this context we think of the data as rotation, a translation and perhaps a scale - not orientation, position, and size. There are appropriate uses of 'rotation' at higher levels in the game code as well. Consider a function like Object::rotate(Quat rotation). Most people would expect this function to accept a change in orientation (aka rotation) and update the object's orientation accordingly. One could argue that in this context 'rotation' does not refer to angular velocity. While not specifically the *time* derivative of orientation, the fact is that the 'rotation' parameter is still some sort of delta of orientation. Instead of a continuous phenomenon, this is simply a discrete event in some ways similar to impulse (force or torque times time) but without the dependence on mass and inertia. The function's usage of rotation is consistent with both the English definition and user's expectations. In comparison consider a the function Object::orient(Quat new_orientation). One would expect it to directly set the orientation of an object based on the input parameter, 'new_orientation', supplied to the function. How the object was facing previously wouldn't affect the result. In both of these examples, both the verb (function name) and noun (parameter name) forms of the term are at the same level. Orient and orientation deal with how something is facing, meanwhile rotate and rotation describe the delta or 1st-derivative of that. Ahhh, it just fits.

How could anybody get so hung up on the usage of one little term? Misuse of the single term rotation is not really that big of a deal. It just happens to be a good example that most people are familiar with. The real problem is that this sort of thing happens fairly frequently with all sorts of terms. Every time a variable, class or function is added, it must be given a name. Most of the time, programmers are bang-on the first time - but not always. With thousands of things to name, some bad choices are inevitable. Its a mistake we all make, if not with physics terms, then with something else. So please do not be offended by this article if you glanced at your own code and saw "rotation" misused. So what, does it even matter? Its true, the "compiler doesn't care". Even the programmer who writes code knows what he meant - even if he wasn't fully accurate with the terminology. Coworkers inbred on the same game team don't seem to have any problems with it either. The negative impact of subtle misuse of terminology only becomes apparent when the scope is increased. For example, this would add to the communication overhead making larger game teams less efficient. Developers suffer unnecessary learning curves if they migrate from one team to another. Looking at the greater development community, the track record for code reuse and standards isn't that great even though so much is available for free. With the notable exception of larger or well-defined (standardized) solutions, too often the cost of trying to use external code exceeds the cost of developing it internally. There are numerous causes why this is so, but getting people to be picky about their variable/function names and speak the same language would help improve the situation.

So how come the industry, full of technology perfectionists, has this propagation of bad terminology? While compilers provide immediate feedback about syntax errors and program misbehavior quickly exposes logic errors, there simply isn't any timely feedback about terminology mistakes. Coding standards are good but don't solve this problem. Things like comment requirements, bracket placement, and variable prefixing do reduce the irritation factor, but only inform the next guy about the obvious. It's the subtle misuse of a term that causes severe pain. It can take a long time before someone else might come along and fully reverse engineer some piece of code and then stand back to take a "fresh look" at it in order to describe a function or variable by what it really is - as opposed to what the original programmer thought he would be doing when he started or just named it wrong because there wasn't time to dwell on labels. Unfortunately, picking the right terms is not a process that can be automated - it takes time and thought. It has more in common with writing an essay where putting a simple idea on paper can take hours or even days. As time elapses, however, details of the implementation are forgotten, developer's interests have moved on, and users become accustom to the initial API. Consequently it becomes harder to make a change to existing code. By the time somebody suggested calling it 'strdiff()' instead of 'strcmp()' they probably just concluded it was too late to change the function name - unfortunately they couldn't foresee the massive time and productivity wasted ($billions) that would result during the decades between then and now. Since individuals are usually judged and rewarded in the short term, there's little room for such long term thinking. Admittedly, making a change does have a cost that isn't always worth it since most code doesn't have a long lifespan. Sometimes it's better to just code and ship. From an individual perspective there is another downside. If other people can easily understand your code then they assume it was easier to write (when in fact the opposite is true) so your contribution is devalued. Furthermore, they may become empowered to do more with your code (without your help) which could make them shine brighter than you. So, depending on your individual circumstances, it might be in your personal financial best interests to do the opposite of everything I'm suggesting.

The case presented today against using rotation to describe orientation may not matter in the long run if enough people misuse the term. Languages evolve and change. The mob rules. How else could you explain all the special cases in grammar and spelling. Observe the usage of the word 'like' in the phrase "he was like, o my gosh - thatz so weird". I wonder how those Oxford English Dictionary scholars are going to add an entry for that one. A rich language isn't always a bad thing. Without ambiguity in the English language, we would have never had the pun-packed Leslie Neilson "Airplane" movies and "Police Squad" series. Unfortunately, spending hours figuring out why someone else's code is doing something different than what's clearly indicated isn't funny at all.