Hi Mike,

>An article espousing meaningless variable names?

I've explained myself badly. <g>

I was thinking of Spartan programming and the generic names technique. The idea here is that many times the name of the variable is actually meaningless because the variable doesn't have any special requirements. For instance, I have a method that converts a string to upper case:

PROCEDURE ToUpperCase(tcString)
RETURN UPPER(m.tcString)

There's absolutely no sensible name for the parameter. You can use tcString, theString, aString, strValue, cValue, tcValue, cData, lpszData.... Most likely you end up with some combination of String, Value, or Data, combined with whatever naming scheme you use. Since there's no obvious name for the parameter, the likelihood increases that similar methods use different names. A month later you might add a ToLowerCase() function:

PROCEDURE ToLowerCase(tcData)
RETURN UPPER(m.tcData)

If you don't look at the previous code and don't have standard names for such generic parameters, you probably end up with different names after some time. Therefore generic naming limits these names to just one letter. For languages that require a type specification this actually makes more sense than in VFP:

void ToLowerCase(String s)
{
  return s.ToLower();
}

Most variables in procedures are generics, especially if procedures are kept short.