How to name variables according to context

Everyone knows that naming variables and such are probably the most difficult job of a programmer. Here, I'm going to give you a few tips that will prevent me from crying when I have to look through your code.

Variable names are too damn long!

So, first things first. Repeat after me: Longer names are not better. In fact, this is what makes naming so hard. You want something as concise as possible that is exactly as descriptive as needed. So, if you ever ask yourself "should I use LengthOfWidget or LengthOfThing" you are doing it wrong! You should be asking yourself "in this context should I be using Length or l" Hint: It's hardly ever the longest one.

There are quite a few things that can go into how descriptive your name should be. Scope is the primary factor.

Example:

class Widget
{
    public int l; //BAD. Not descriptive enough (assuming it means length)
    public int Width; //appropriate
    public void DoStuff()
    {
      public int count=0; //appropriate
      ....
      for(int index=0;i<count;index++) //BAD. Too damn long!
      {
          stuff[index].FooBar=true;
      }
      for(int i=0;i<count;i++) //appropriate
      {
          meh[i].Foo=false;
      }
    }
}

So, as you can see, long names are bad when their scope is very narrow. In general, you should be able to get an idea of what something means from public class names. However, you should not be able to know exactly what a local variable does just from the name. Local variables are just that, local. Because clean code mandates that a method usually fit within a screen full of code, this means it doesn't matter that you don't immediately know what it is. Repeat after me it does not matter if my variable names are less than 4 letters long(sometimes). The reason? Because you can figure out the meaning relatively quickly from context!

Also, avoid modern hungarian notation. There was literally a line of code like this in the product I work on (as a local variable that was used twice):

int methodCountForType = type.Methods.Count;

What does this local variable name add to a 10 line function? Try to find one good thing about it, other than to practice your typing skills.

Long variable names are not more useful

And, this brings me to my next point. "But my public variable names are too long". If you have trouble condensing your variable names down into something easy to type, it's a code smell. It's not guaranteed your code is bad or anything, but having a method like ComputeAreaAndMultiplyBy20, it's probably a good indication that you should split it up into ComputeArea and Multiply. Of course, there are some names that are generally hard to make concise. But in general, if your name is painfully long, ensure that you shouldn't break up that method or encapsulate it in a different class.

shorter names are actually more readable

So, in conclusion. Stop using ridiculously long variable names for ridiculously short scopes! Future programmers(who may be psyco-ax-murderers) will thank you for not making code that much less readable and harder to type.

Also, don't assume intellisense/word-completion exists everywhere. A 40 character name is NOT ok. I don't give a damn if my IDE can make it so I only have to type 3 of those characters.

(also, just in case you're wondering, this is my first real use of memes in a blog post. Forgive me if it wasn't the best.. I'm trying new things :) )

Posted: 1/17/2013 7:08:54 AM

Comments

Posting comments is currently disabled(probably due to spam)