Using var and temporary variables

Very often, I use short variable names such as 'i', 'ctr', 'idx'. As you can tell from the name, generally these are used for iterating through a collection.

For me, I will use one of these if it's something quick and easy such as a fairly simple sort or filtering. Generally these are short (there are maybe one or two lines of code) and there aren't any other variables used.

Similarly for 'var', a C#-specific feature which I tend to use when working with LINQ but don't really need to keep the intermediate results. If I need the results, I usually convert to a List and that has a fairly descriptive name as well.

I also use it in GUI programming with Button events. Again, it's only a few lines of code and I only need it a few times at most. Most of the time, it's just created so I can call Show(). You could just create it without assigning it to a variable but it's not that at all difficult and could come in handy later if debugging is needed.


I would not recommend these for any code that spans more than maybe 1/2 a code page or for things that you can't understand what the code is doing within a few seconds, like algorithms.

Speaking of algorithms, some people like using names like 'a', 'b', 'c' but most algorithms are long and/or hard to understand. Usually for things like nested loops or involve a lots of other variables, I use better names.

For example, iterating through a table, I will use 'row', or 'col' if I am doing a lot with the data. If it's just a simple copy, probably 'r', 'c' is good enough.

But going back to algorithms particularly, I try to use names that are more descriptive so that people, myself included when I'm reviewing the code, don't need to spend 10 minutes figuring out what each one means.

I have spent a lot of time walking through code to figure out what it does because other developers have done and furthermore they don't even leave any comments. That's another thing, if something is complicated, or goes against usual conventions for some reason, leave a good comment that will let others or yourself immediately understand what's going on.

Why use readonly (versus const)

I was playing around with Resharper today and ran a code analysis on one of my projects which came back with 430 code issues. One of the suggestions said there were fields I should mark as 'readonly'. And this then reminded me of this question I've sometimes been wondering.

Today I finally Googled it and it resulted in a "Oh yeah..." moment. The top answer in StackOverflow being:

The readonly keyword is used to declare a member variable a constant, but allows the value to be calculated at runtime. This differs from a constant declared with the const modifier, which must have its value set at compile time. 

 I've run into this problem many times before where I try to assign DateTime (for something like Today) or a List (of required names) into constant variable. Up until now my solution was just remove the 'const' modifier.

Also readonly allows the class to assign it during the constructor so if for example you need one instance, which should never be reassigned after initialization, but need to also do some set up work, readonly would be a good use for that... if the object is used within the class only.

If the object is also public though, you make want to consider using a getter instead like in the singleton pattern.

I usually use readonly on ViewModels as when a window is initialized, these are created but should never be replaced afterwards. It's probably a no-brainer but just for some added insurance, you can use the readonly modifier on it.

And Resharper made my Visual Studio really slow... so bye bye Resharper!