When should you use var versus an explicit type?

• Readability decision – Choosing between var and an explicit type is purely about the human reading the code, since both produce identical bytecode.
• Good for var – Constructor calls, complex generic types, stream pipeline intermediates, and for-each variables where the element type is clear.
• Bad for var – Unclear method returns, primitives whose width matters (int vs long), and situations where an explicit type acts as a contract tripwire.
• Contract tripwire – An explicit type fails to compile if a method's return type changes, while var silently re-infers.
• Hard prohibitions – var cannot be used for fields, method parameters, return types, or lambda parameters without a target type.

When is var a good choice?

var is best when the right-hand side already makes the type obvious. The reader does not lose any information.

package com.bank.service;

import java.math.BigDecimal;
import java.util.*;
import java.util.stream.Collectors;

public class VarGoodCases {

    public void constructorCall() {
        // Type is literally in the initializer
        var account = new SavingsAccount("SAV2001");
        var balance = new BigDecimal("50000.00");
    }

    public void complexGenerics() {
        // Long generic type written twice is noisy
        var byAccount = new HashMap<String, List<Transaction>>();
        var monthlyTotals = new TreeMap<String, BigDecimal>();
    }

    public void streamPipeline() {
        List<Transaction> txns = loadTransactions();
        // Collector type is just noise
        var grouped = txns.stream()
                .collect(Collectors.groupingBy(
                    Transaction::getAccountId));
    }

    public void forEachLoop() {
        List<Account> accounts = loadAccounts();
        // Element type is obvious from the collection
        for (var account : accounts) {
            System.out.println(account.getId());
        }
    }
}

When should you avoid var?

Avoid var when the type is the information the reader needs. Three cases stand out.

package com.bank.service;

import java.math.BigDecimal;

public class VarBadCases {

    // BAD: unclear method return
    public void unclearReturn() {
        // var result = reconcile(); // What type is result?
        // BETTER:
        BigDecimal result = reconcile(); // Documents intent
    }

    // BAD: primitive width matters
    public void primitiveWidth() {
        var count = 0;    // int: overflows at 2.1 billion
        // If summing paise across millions of transactions:
        long paiseTotal = 0L; // Explicit type prevents overflow bug
    }

    // BAD: var hides a contract change
    public void contractTripwire() {
        // If getBalance() changes from BigDecimal to BalanceWrapper:
        // var balance = service.getBalance(); // silently re-infers
        BigDecimal balance = service.getBalance(); // fails to compile
    }

    private BigDecimal reconcile() {
        return new BigDecimal("100000.00");
    }
}

How does var act as a contract tripwire?

An explicit type catches return-type changes at compile time. var silently re-infers and keeps compiling, which can hide a breaking contract change.

package com.bank.service;

import java.math.BigDecimal;

public class ContractTripwireDemo {

    // Original method returns BigDecimal
    // Later someone changes it to return BalanceWrapper

    // With var: compiles both times, bug hides
    public void withVar() {
        var balance = getBalance(); // re-infers silently
    }

    // With explicit type: fails to compile when return changes
    public void withExplicit() {
        BigDecimal balance = getBalance(); // compile error if changed!
    }

    private BigDecimal getBalance() {
        return new BigDecimal("75000.00");
    }
}

What is the diamond operator trap with var?

var list = new ArrayList<>() infers ArrayList