Do you use 1-3 letters variables EVERYWHERE? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 6 years ago.

Improve this question

I notice, in C# i use very short variable names EVERYWHERE. My code is pollut开发者_如何学Pythoned with

foreach(var (v|f|i) in SOMETHING)

for(int (i|n|z)=0

var (ret|r) = blah();
...
return ret;

var sw = new StringWriter();

using(var r = cmd.ExecuteNonQuery()) {
    while(r.Read()) {
        r.GetSomething(3)

I dont know if this is bad or ok. I can certainly read it. I havent looked at code 5months ago or older so i cant say if i understand old code. All my functions are short and do one thing so by reading the function you can get a good idea what the variable is, especially since theres <=5vars in a function.

People use to yell at me about not using good variable names. Am i not using good variable names or is this ok?

---

Write code for humans to read. A good rule of thumb is the bigger the scope in which a variable is used, the more descriptive its name should be. Function parameters especially should have very descriptive names, with the exception of functions where it is obvious what the parameter does, as in
double sqrt(double n)

However, if it's something commonly given a short name and used in a small scope, then use a short name. Examples:

//these are okay
var sb = new StringBuilder();
var sw = new StringWriter();
var cmd = new SqlCommand();
for(var i = 0; i< count; i++) {}

---

Unless your code is minified, you shouldn't see vars like this all over the place. Your code should be effortlessly intelligible.

I recall hearing that we ought all code as if the next person to manage our project is a psychopathic killer who knows where you live.

---

Using short variable names for local variables is okay as long as the scope is limited.

Personally, I find that for simple usage short concise variable names tend to be easier to read than longer ones.

using (StreamReader sr = new StreamReader(inputStream))
{
    sr.ReadByte();
} 

As opposed to:

using (StreamReader streamReader = new StreamReader(inputStream))
{
    streamReader.ReadByte();
} 

It's really all about readability. Every situation is different, and developer teams are different. Follow the coding standard for the project, if that exists. If not, follow the style of existing codebase, if that exists.

I agree with some of the answers here say that variables names should have good names. But I believe that presupposes that an object has semantic value. Sometimes, it doesn't. In some cases, you just need an instance of a specific object to perform some small task, after which it becomes irrelevant. In cases like this, I believe that abbreviated identifiers are acceptable.

Note: Just because the usage of a variable is limited in its scope does not necessarily mean that an meaningless name is okay. If there is a good name that represents what the object does, then it should be used. If you can come up with a variable name that answers 'Why?', then that name is far preferable.

Also, using 'i' and 'j' for for indexes is well understood by developers. By convention, loop counter variables have been named this way since the days of FORTRAN.

for (int i = 0; i < 10; i++)
{
    for (int j = 0; j < 10; j++)
    {
        PerformOperation(i,j);
    }
}

---

Some years ago I discovered what happens if I made my functions short:

• I could understand them. My brain is small, and long functions don't fit.

• Classes get complicated (lots of functions). But Extract Class produced small, cohesive, single-purpose classes. Again, small brain, so small classes required.

• The number of variables in a function (or class) is small. Remembering which is which from declaration time to use time is easy, because the distance is short.

• The number of scopes in my functions is small, so I don't have to figure out which variables go where.

With all of that in place, how I name my variables doesn't matter much. The names don't have to make up for code that is otherwise hard to understand.

Since the number of variables in a scope is small, and the purpose obvious, I rarely need to put any effort in to choosing a descriptive name. Since I don't want to strain my small brain any more than I have to, I never abbreviate. My default name for a variable is the name of the type. E.g. class Foo goes in variable foo. In my code, if it's ever something different, you know something special is happening, and you should pay attention.

In the old days, my no-abbreviation habit would have produce unwieldy code, but since my methods and classes are small, the code doesn't suffer.

---

It's not just a matter of good variable names (which is a good idea) but rather if someone else could make sense of what you've written relying on the comments as well as the variable names.

Sure, for things like counters or simple actions short and concise names make sense. For more complex algorithms or something that is a little harder to read, you'll want to elaborate to the extent that the code is clear.

Every shop and every developer is different. At the end of the day, try to write your code with consideration for the next guy that might have to maintain it.

---

Using one letter variable names as indexes in loops or in short well defined blocks is normally considered ok. However, there is nothing wrong with using descriptive camel case names that convey meaning to others reading your code, for things like function arguments and local variables.

---

With limited exceptions, no - this is not OK. There's just no excuse any longer for single letter or overly abbreviated variable names. Even if you're a hunt-and-peck typist, intellisense means you almost never have to spell anything out. If you continue to name variables this way you are punishing both yourself any anyone unfortunate enough to be tasked with maintaining your code.

---

Would I consider it a bad coding style? Well, yes.

If you were working with me on same code I'd repeatedly remind you to name your variables better. In short, good code should be readable by other developers without much trouble and good variable names help a lot. Maybe you don't have problems reading your code even after a while, but the question is whether someone who has never worked on that good would be equally fine with it.

There are a few exceptions where I think that short variable names are okay:

Indexes (mostly in for loops) such as:

for (int i = 0; i < 10; i++)
{
}

Variables used in a very limited scope, such as Linq queries, lambda expressions or some of the examples already mentioned like Streamwriters and -readers and such are another example where I think that short variable names are fine.

Furthermore it's always a question of how readable your code eventually is. The reason why I would be constantly nagging at people who use short variable names is that for me that it is an indicator that they generally don't care about how readable their code is (especially for others).

---

I have no idea how you can keep track of things when you have variable names like that.

Generally, its much better to have longer names that actually describe the variables. The thing to strive for is for anyone to be able to read the code and understand whats going on, to be able to understand what they are for etc =)

---

It seems like the average length of my variable names increases by one every year I spend writing (and more importantly reading) code.

---

It should be immediately clear what any variable is for just by looking at a few lines of code. This can either be due to a nice variable name or the context.

About the only time I use short variable names is either if a short name is entirely descriptive (ie, x & y in a situation dealing with coordinates) or it's a utility function that operates on a data type (ie, capitalize the first letter of this string. It's a string, what else can you say about it? I named it S.)

---

I might not know what 'r' is later on in the code. Also, variable names are one thing, but you should be commenting code for the verbose explanation. NB: This should probably be a community wiki as there's no definite answer.

---

This is bad. This is unmaintainable.

Short variables have their place. There is really no reason to write for(int iterator; iterator

The rule of thumb is: One letter per screen of reach. With standarized 24 lines screen.

The exception is picking one-two extremely frequently used globals or semi-globals like pointer to the data storage or THE input data pointer, and make them 1-3 letters long. But anything else - use reason. Short loops - one letter. Locals of a function - 3-5 letters. Class variables - full word. Library class/function names - two words.

---

I don't see any reason to use short variable names that say nothing. We live in 21st century, we've got IDEs with IntelliSense (or other autocompletion)! Just press Ctrl+Space and it will advice you normal name for your variable depending on variable type, e.g.

StringBuilder <Ctrl+Space> stringBuilder;
List<Person> <Ctrl+Space> persons;

It is even easier than to type something like sb or another short name. No reason to use short names anymore.

P.S.: The only exception for me are counters like i, j, k in for loop.

---

I tend to prefer short "cryptic" variables (Symbols, in Mathematica) combined with descriptive comments.

Mathematica already has VeryLongFunctionNames for built in commands, and adding my own often spreads out code more than I care for.

I find it easier to read a shorter block of code where I can see everything at once, alongside a series of symbol descriptions.