You'd think this would be obvious but it's surprising how often I run into source code that doesn't use self documenting names. Many developers will use the shortest names possible. I'm sure plenty of my old code is this way. Some of you may have asthetic reasons for short names. I'd argue asthetics should come after logic and practicality. You're goal should be to write code fast with as few complications and bugs as possible. Code that is easy for others to understand so that they also don't get confused and run into bugs.

Let me attempt to point out some examples of self documenting names and non−self documenting names and the problems they cause.

void DrawLine(float x, float y, unsigned int color); // <- bad

This looks like a straight forward function except what is color? Is it in the format 0xAARRGGBB or 0xRRGGBBAA or 0xAABBGGRR or maybe something else entirely. Any time wasted looking up what it's supposed to be is one more reason you're going to be sitting at your desk late at night instead of out and about.

void DrawLine(float x, float y, unsigned int colorRGBA); // <- better.

Now it's very clear. Color is 0xRRGGBBAA format so 0xFF0000FF would give you 100% red.

Someone might suggest instead of the type being unsigned int, maybe it should be custom type. That's fine, just name the type something clear. typedef unsigned int ColorRGBA not typedef unsigned int Color

void DrawLine(float xPixels, float yPixels, unsigned int colorRGBA); // <- best

Ah ha!, x and y are in pixels.

How about this one.

void copy(thing* a, thing* b); // <- bad.

does this copy a−>b or b<−a?

void copy(thing* a, const thing* b); // <- better.

That helped beacuse obviously we can't copy a−>b if b is const but assume the copy function is 100 lines long. Maybe it's copying an array of something and inside there's something like copyarray(a.m_arrayData, b.m_arrayData). Again, looking at that single line I'd have to go reference the definition of a and b to know which side is the source and which is the dest.

void copy(thing* dst, const things* src); // <- best.

This one obviously we copy src−>dst, no parsing the code required. And lines like this copyarray(dst.m_arrayData, src.m_arrayData) inside copy will now be readable without having to reference anything else.

Here's some others:

float rotationAmount; // <- bad
float rotationAmountInRadians; // <- better, we know they are radians
float rotationAmountInRadiansPerSecond; // <- best, we know 100% what it is

vector3::velocity; // <- bad
vector3::velocityInMeters; // <- better
vector3::velocityInMetersPerSecond; // <- best

void Update(float elapsedTime); // <- bad
void Update(float elapsedTimeInSeconds); // <- good, ah, it's in seconds.

I heard one programmer object that time wasn't always in seconds because sometimes (bullet time) he slowed down the game. That's pretty much irrelevant though, in his game all calculations are done as though the time passed in is in seconds. It's good to know the time is in seconds, not in frames or some other unit. Name it!

Note that it's okay to shorten or abbreviate. Just be consistent MPerSec or InSec or use a prefix secsElapsed, mpersecVelocity. A very good article that also deals with similar issues this Joel's "Making Wrong Code Look Wrong"

These ideas are not about being a code nazi. They are about being efficient and avoiding bugs. Every one of these has bitten me before. I've had to dig through levels of library code to find out which is source and which is dest in a function. I've spent hours trying to figure out why something did not appear on screen because I was passing radians when the function in question wanted degrees but because the docs just said "rotation" and because the argument was just called "rotation" it didn't even cross my mind until hours of tracking down the issue.

Another common excuse some programmer will bring up is because their editor shows the help or function signatures or has other kinds of helpful features that they don't need to follow these guidelines. That might be true if you're a one man team. On anything larger other programmers are likely to be using different editors which may or may not bring up the same help. I know that in my current project I use both Visual Studio and Visual Slickedit and neither bring up all our help.

So, help out your fellow programmers and automatically document your code by choosing variable names that make the code easier to understand. If I had followed these rules I'd have had to work less, gone home to be with my girlfriend, or moved on to the next feature instead of wasting time figuring out things or tracking down bugs that could be avoided by simply naming things better.