DEV Community

Cover image for To var or Not
Stas Sultanov
Stas Sultanov

Posted on • Edited on

To var or Not

var is a C# keyword introduced in version 3.0 (year 2007) to simplify variable declarations by eliminating redundant type specifications.

Despite its straightforward purpose and clear benefits, many developers still passionately debate its use.

Some argue that var should never be used. Others say it's acceptable, but only when the type is immediately clear. Discussions flare around readability, maintainability, and clarity — as if we're still programming on punch cards.

Every time I come across these arguments, I can't help but wonder:
Seriously, what year are these people living in?

Critics of var frequently overlook one crucial reality:
For decades, we've been working with code via powerful IDEs.

Modern IDEs like Visual Studio, Rider, or VS Code provide instant clarity about every aspect of your code, including variables declared using var.

The IDE always knows the variable's type — just hover your pointer.

The idea that var hides the type is simply outdated.
Such concerns might have had merit decades ago, during the era of monochrome displays and basic text editors, but today they're irrelevant.

Some gifted individuals still claim it’s hard to understand the type behind var — usually while reviewing pull requests or browsing code on GitHub’s web interface.

My take? If you’re doing serious code review or exploration, you should be using a proper tool — like VS Code with GitHub extensions.

So, the real problem isn’t var. It’s using the wrong tools for the job.

Conclusion

Use var wherever it is possible.


P.S.

Back in the 1980s, C++ developers started prefixing class members with m_ to distinguish them from method parameters and variables.
It made sense at the time — there were no IDEs, no semantic highlighting, no code navigation. It was a practical workaround for working in primitive environments.

By the late 1990s, IDEs like Visual Studio made that convention obsolete. Syntax highlighting and intelligent tooling eliminated the need for such manual tricks.
Yet some developers still cling to m_.
Not because it helps — but because it’s what they’re used to.

That’s not engineering discipline. That’s fossilized thinking.

The resistance to var today is cut from the same cloth. It's not about clarity. It's about being stuck in habits that modern tools have already outgrown.

Top comments (0)