Introduction

ReSharper does not actually want var for everything by default because var is universally superior. It suggests var based on a configurable style rule that assumes local code is often easier to read when the right-hand side already makes the type obvious.

What var Really Means in C#

var is not dynamic typing. The compiler still infers one static type at compile time.

var count = 5;              // int
var name = "Mina";          // string
var stream = File.OpenRead("data.txt"); // FileStream

After compilation, each variable has a concrete type exactly as if you had written it explicitly. So the ReSharper suggestion is a style preference, not a semantic rewrite of the language.

Why Tools Prefer var in Obvious Cases

When the type is already clear from the expression, repeating it can add noise without adding information.

Customer customer = new Customer();

Many teams prefer:

var customer = new Customer();

In this case the constructor already tells you the type. ReSharper often treats that as the cleaner option because the line emphasizes the variable name and intent rather than duplicating the type.

This is especially common with:

• 'new SomeType(...)'
• LINQ projections
• long generic types
• anonymous types where explicit typing is impossible anyway

Why Some Developers Disagree

The argument against var is usually about readability in less obvious code.

var result = service.Get();

Without more context, result could be many things. Some teams prefer:

OrderSummary result = service.Get();

That makes the type visible at the point of use. ReSharper can be configured to respect this preference too. The point is not that one style is objectively correct in every case, but that a codebase should choose a rule that makes review and maintenance consistent.

ReSharper Uses Configurable Inspection Rules

ReSharper has code style settings for implicit versus explicit typing. You can tell it to:

• use var everywhere
• use var only when the type is evident
• prefer explicit types in ambiguous cases

That means the suggestion you see reflects the team's or local profile's settings, not a hard language requirement.

A common compromise is:

• 'var for obvious constructor calls'
• 'var for anonymous types and LINQ'
• explicit types when the right-hand side hides the real type

That policy aligns with how many experienced C# teams write local variables.

Readability Depends More on Naming Than on var

People often focus on the keyword and ignore the larger issue: a vague variable name can make code unclear regardless of whether the type is explicit.

var x = repository.Load();

is worse than:

var activeOrders = repository.LoadActiveOrders();

Clear names, small methods, and obvious expressions usually matter more than whether the local variable uses var or an explicit type.

Common Pitfalls

• Assuming var means runtime dynamic typing in normal C# code.
• Treating ReSharper suggestions as language rules rather than configurable style settings.
• Using var when the right-hand side hides the type and hurts readability.
• Banning var completely and creating repetitive noise in obvious constructor calls.
• Debating the keyword endlessly instead of agreeing on a consistent team style.

Summary

• ReSharper suggests var because many code style profiles prefer implicit typing when the type is obvious.
• 'var still produces a concrete compile-time type.'
• The real tradeoff is readability, not correctness.
• ReSharper can be configured to prefer explicit types where they add clarity.
• Consistency across the codebase matters more than winning a style argument on one line.