a common mistake when using Variables And Short Declaration

Beginner·3 min read

Fast recall

Quick revision

Core answer

A common mistake with the difference between var and := in Go is using the rule without checking its boundary conditions. var declares a variable and may use an explicit type; := infers the type and is allowed only inside functions. That can make a valid-looking result fail for an empty input, a nil value, a duplicate, or a different ordering. I prevent it by naming the assumption, testing the boundary, and checking the result against a small hand-worked example.

Interview-ready guide

Interview answer

The most common mistake with := is accidental shadowing. A short declaration can create a new variable in an inner scope even when a variable with the same name already exists outside it. The inner value then disappears at the closing brace, while the outer value remains unchanged.
For example, suppose a function declares var err error and then uses if enabled { result, err := load() }. The result name is new inside the block, so the statement can also create an inner err. Checking the outer err afterward may incorrectly show nil, hiding the failure returned by load.
I prevent that by deciding which values must survive the block. If result and err are needed later, I declare them in the outer scope and write result, err = load(). If they are only needed inside the block, the short declaration is appropriate and the limited scope is helpful.
Another mistake is using := when every name on the left already exists in the same scope. After count := 1, writing count := 2 fails with “no new variables on left side of :=”. That statement is an assignment and must be written as count = 2.
The opposite mistake is forcing := where var expresses intent better. A zero-value declaration such as var buffer bytes.Buffer is already ready to use and avoids manufacturing an empty initializer merely to use short syntax.
Tooling helps here: the compiler catches the no-new-variable case, while go vet, static analysis, careful scoping, and focused tests can expose shadowing. During review I pay special attention to short declarations inside if, for, and switch blocks.
The rule I remember is that := declares at least one name in the current scope. Whenever I only intend to update existing state, I use = explicitly.

03 · Deep dive

a common mistake when using Variables And Short Declaration

About 2 min with examples

Direct Answer

Deep Dive & Architecture

Use var when declaring a package-level variable, when you want a variable to begin with its zero value, or when an explicit type makes the code clearer.

Use := for short local declarations inside a function when the initial value already makes the type obvious.

Both create typed variables; the important differences are scope, initialization, and readability—not runtime speed.

A common mistake is using := at package scope or assuming it redeclares every name.

Code Example

var retries int
name := "Ada"
retries, name = 2, "Grace"

Common Mistakes & Pitfalls

Giving a slogan about the difference between var and := in Go without checking its scope, boundary cases, or trade-offs.

Check your understanding

Answer these without looking back at the article.

When would you use Variables And Short Declaration in a real project?
What is the difference between var and := in Go?
When should you use var instead of := in Go?

When would you use Variables And Short Declaration in a real project

Continue · Next question · Q 4/40

When to use var instead of := in Go

Full prep

Looking for a structured roadmap?

Every module on this page is also part of the full Java backend interview track.

Open the full roadmap Browse all prep categories

a common mistake when using Variables And Short Declaration

Beginner·3 min read

Fast recall

Quick revision

Core answer

The most common mistake with := is accidental shadowing. A short declaration can create a new variable in an inner scope even when a variable with the same name already exists outside it. The inner value then disappears at the closing brace, while the outer value remains unchanged.
For example, suppose a function declares var err error and then uses if enabled { result, err := load() }. The result name is new inside the block, so the statement can also create an inner err. Checking the outer err afterward may incorrectly show nil, hiding the failure returned by load.
I prevent that by deciding which values must survive the block. If result and err are needed later, I declare them in the outer scope and write result, err = load(). If they are only needed inside the block, the short declaration is appropriate and the limited scope is helpful.
Another mistake is using := when every name on the left already exists in the same scope. After count := 1, writing count := 2 fails with “no new variables on left side of :=”. That statement is an assignment and must be written as count = 2.
The opposite mistake is forcing := where var expresses intent better. A zero-value declaration such as var buffer bytes.Buffer is already ready to use and avoids manufacturing an empty initializer merely to use short syntax.
Tooling helps here: the compiler catches the no-new-variable case, while go vet, static analysis, careful scoping, and focused tests can expose shadowing. During review I pay special attention to short declarations inside if, for, and switch blocks.
The rule I remember is that := declares at least one name in the current scope. Whenever I only intend to update existing state, I use = explicitly.

Interview-ready guide

Interview answer

The most common mistake with := is accidental shadowing. A short declaration can create a new variable in an inner scope even when a variable with the same name already exists outside it. The inner value then disappears at the closing brace, while the outer value remains unchanged.
For example, suppose a function declares var err error and then uses if enabled { result, err := load() }. The result name is new inside the block, so the statement can also create an inner err. Checking the outer err afterward may incorrectly show nil, hiding the failure returned by load.
I prevent that by deciding which values must survive the block. If result and err are needed later, I declare them in the outer scope and write result, err = load(). If they are only needed inside the block, the short declaration is appropriate and the limited scope is helpful.
Another mistake is using := when every name on the left already exists in the same scope. After count := 1, writing count := 2 fails with “no new variables on left side of :=”. That statement is an assignment and must be written as count = 2.
The opposite mistake is forcing := where var expresses intent better. A zero-value declaration such as var buffer bytes.Buffer is already ready to use and avoids manufacturing an empty initializer merely to use short syntax.
Tooling helps here: the compiler catches the no-new-variable case, while go vet, static analysis, careful scoping, and focused tests can expose shadowing. During review I pay special attention to short declarations inside if, for, and switch blocks.
The rule I remember is that := declares at least one name in the current scope. Whenever I only intend to update existing state, I use = explicitly.

03 · Deep dive

a common mistake when using Variables And Short Declaration

About 2 min with examples

Direct Answer

Deep Dive & Architecture

Use var when declaring a package-level variable, when you want a variable to begin with its zero value, or when an explicit type makes the code clearer.

Use := for short local declarations inside a function when the initial value already makes the type obvious.

Both create typed variables; the important differences are scope, initialization, and readability—not runtime speed.

A common mistake is using := at package scope or assuming it redeclares every name.

Code Example

var retries int
name := "Ada"
retries, name = 2, "Grace"

Common Mistakes & Pitfalls

Giving a slogan about the difference between var and := in Go without checking its scope, boundary cases, or trade-offs.

Check your understanding

Answer these without looking back at the article.

When would you use Variables And Short Declaration in a real project?
What is the difference between var and := in Go?
When should you use var instead of := in Go?

Full prep

Looking for a structured roadmap?

Every module on this page is also part of the full Java backend interview track.

Open the full roadmap Browse all prep categories