I got asked today about my use of “var” in .NET. As it happens in every debate, I forgot all reasons of why I use “var.” After thinking about it, the main reason is, and always will be, “I like var.;” it’s concise, it’s easy to read, and it saves me time typing more complex types. I have never found myself wondering what type the variables is, so I don’t care about the way I declare its type. I only care about how I use that type. But unlike Jim Jeffries common argument for guns: “*!@$ you! I like guns!” (as described in his standup on YouTube: https://www.youtube.com/watch?v=0rR9IaXH1M0), which I agree is a perfectly valid argument for doing something, there is more reasons to using “var.” So I will talk about each one in turn.
- It’s as readable as the implicit type declaration. It makes no difference whether you declare your type before or after the variable. The following are the same.
var widgets = List<Widgets>();
- I don’t have to repeat myself. I am lazy, even more so when I write code. I can “get two birds stoned at once!” So doing this:
var widgets = List<Widgets>();
Is easier to write than this:
List<Widgets> widgets = new List<Widget>();
- I get the benefit of my variable never being null! No more “Object reference not set to instance of an object!” Sure, this is not a problem for simple types like string, int, but it’s a pain in the ass for and lists like List<Widget>. How many times have you declared your list, forgot to initialize it, then try to put junk in it?! I know I have!
- Using “var” is only allowed in local scope, which means that every time I declare something with “var”, you know it will be only available in the local scope. Thank you Captain Obvious!
- I don’t care what the compiler does with it when it compiles! It’s none of my business.
A Sidebar on Code Readability
The bigger issue with readability that most folks miss, is how you name your variables and how you structure your code. Here are a couple of things that make code much harder to read:
- Variable names after single letters. “L” or “R” might mean something to you if you wrote the code, but to anyone new looking at it, it might as well be Greek. Which is great if you are Greek but not so much for everyone else. How about “Log” or “Result?”
- Function size. If your function is bigger than a page, and I have to scroll to read it, you are doing it wrong.
- Inconsistent capitalization. A widely accepted standard is that parameters are camelCase, private _variables are small case and can start with “_” and public Properties are title case.
- Too many parameters. If a function has more than 2-3 parameters, it’s time to make a object to pass those parameters. Readability goes out the window when function parameters start spanning multiple lines.
- Silly patterns that somehow still persists. By that I am talking about variables having the type letter in the name, such as “bFlag” or “iNumber.” Is “b” byte, is it bool? A better choice would be “IsFlag.” There is nothing to be gained by specifying the type in the variable name. The IDE already knows the type, and you have all the intellisense associated with that type.
- Multiline strings. Inline SQL is the poster child for this. A slightly better approach is put your multiline string at the bottom of your class and use some string replacement to fill out it’s values at runtime. Use verbatim strings if you want multiline strings that you can copy/paste in other places. Or better, use an ORM, that’s what they are for!
Credit where it’s due, in no particular order: Burton Rheutan, Endurance Idehen, James Allen.