Shocking Var Vs Val Truth Ruins Bad Code
var and val in Kotlin are both used to declare variables, but the key difference is simple: var can be reassigned, while val cannot be reassigned after initialization. In practical terms, use val when the reference should stay fixed and var when the value needs to change.
What they mean
In Kotlin, val creates a read-only reference, which means the name can be assigned once but not pointed at a different value later. var creates a mutable reference, which means you can update it repeatedly during program execution. This distinction is one reason Kotlin encourages safer, more predictable code by making immutability the default choice whenever possible.
| Keyword | Meaning | Can reassign? | Typical use |
|---|---|---|---|
| val | Read-only reference | No | Constants, stable values, safer defaults |
| var | Mutable reference | Yes | Counters, state that changes, loop values |
Core rule
The easiest way to remember the difference is this: val means "assign once," while var means "assign many times." That rule applies to the variable name itself, not necessarily to every object it points to. A val object can still contain mutable properties if the object type allows it, which is why read-only reference and true immutability are not always the same thing.
"Use val by default, and switch to var only when you truly need reassignment."
Examples
Here is the practical difference in code: a count declared with var can be incremented, while a name declared with val cannot be reassigned. That makes val ideal for values like IDs, configuration settings, and function results that should stay stable after creation.
var count = 1
count = 2 // allowed
val name = "Ava"
// name = "Noah" // not allowed
Why Kotlin prefers val
Kotlin's design nudges developers toward safer code by making val the default habit. Code built around read-only references is generally easier to reason about, easier to test, and less likely to break because of accidental reassignment. Industry guidance and tutorial material consistently recommend using val wherever possible, reserving var for values that really need to change over time.
- val reduces accidental state changes.
- val improves readability because readers know the reference will not change.
- var is useful for counters, loading states, and temporary values.
- var increases flexibility but also increases the chance of bugs if overused.
Common mistakes
One common mistake is assuming val means the object itself can never change. In reality, val only prevents reassignment of the reference, so mutable collections or objects can still change internally unless the underlying type is also immutable. Another frequent mistake is using var by habit, which makes code harder to track because any later line may overwrite the value.
- Use val for values that should stay the same.
- Use var only when reassignment is part of the logic.
- Do not confuse read-only references with deep immutability.
- Prefer the narrowest scope possible for both keywords.
Performance and design
In everyday Kotlin code, the difference between val and var is mostly about design, not speed. The real win comes from writing code with fewer moving parts, because stable references are easier for humans to understand and for tools to analyze. Some developers also note that val can support more predictable optimizations, but the main benefit is cleaner architecture rather than dramatic runtime gains.
Historical context
Kotlin introduced this split to make immutability visible at the language level, reflecting a broader shift in modern software development toward safer defaults. The language became publicly announced in 2011, and its later rise on Android amplified the importance of concise, readable declarations like val and var. By 2025, mainstream Kotlin tutorials still framed the rule the same way: default to val, use var only when a value must change.
When to use each
Choose val for user names, API results, tokens, formatted strings, and objects you do not intend to rebind. Choose var for counters, toggles, progress values, cached fields that refresh, and loop control variables. The best practical habit is to start with val and upgrade to var only when the compiler or your logic proves that reassignment is necessary.
| Situation | Better choice | Reason |
|---|---|---|
| User profile name | val | Should not change during the block |
| Loop counter | var | Needs to update repeatedly |
| API response object | val | Reference should remain stable |
| Loading flag | var | Often flips between true and false |
FAQ
Bottom-line rule
The difference between var and val is reassignment: one is mutable, the other is read-only. If you remember just one rule, remember this: start with val, reach for var only when your logic truly depends on change.
Everything you need to know about Shocking Var Vs Val Truth Ruins Bad Code
Is val the same as final?
val is similar to Java's final for references, because the variable cannot be reassigned after initialization. The difference is that Kotlin still distinguishes between read-only references and the deeper question of whether the object's internal state is mutable.
Can a val object still change?
Yes, if the object itself is mutable. A val prevents you from assigning a new object to the name, but it does not automatically freeze every property inside that object.
Should I always use val?
Use val whenever possible because it makes code easier to read and safer to maintain. Switch to var only when the value must legitimately change as part of the program's logic.
Does var mean bad code?
No, var is not bad; it is simply more flexible. Good Kotlin code uses var intentionally, not casually, so the mutable parts of a program stay limited and obvious.