Go Programming Fundamentals · Go Basics

Variables, Types, and Control Flow

Q: When would you use `:=` versus `var name Type = value`?

## Summary `:=` is for concise declarations inside a function where the type can be inferred from the value; `var` is needed at package level, or when you want to be explicit about the type regardless of the initial value. ## Longer Answer `:=` is for concise declarations inside a function where the type can be inferred from the value; `var` is needed at package level, or when you want to be explicit about the type regardless of the initial value. `:=` is shorthand only valid inside function bodies — package-level declarations must use `var`. In practice, explain where this shows up in production code, what tradeoffs matter, and how you would justify the choice in an interview. ## Key Points - `:=` is for concise declarations inside a function where the type can be inferred from the value; `var` is needed at package level, or when you want to be explicit about the type regardless of the initial value - `:=` is shorthand only valid inside function bodies — package-level declarations must use `var` - In practice, explain where this shows up in production code, what tradeoffs matter, and how you would justify the choice in an interview - Use the answer to connect the concept back to a realistic production or interview scenario for 'When would you use `:=` versus `var name Type = value`?' ## Comparison / Tradeoffs | Aspect | Notes | | --- | --- | | Core idea | `:=` is for concise declarations inside a function where the type can be inferred from the value; `var` is needed at package level, or when you want to be explicit about the type regardless of the initial value. | | Practical tradeoff | `:=` is shorthand only valid inside function bodies — package-level declarations must use `var`. |

Q: Why does Go have only one looping keyword, `for`, instead of separate `while`/`do-while` constructs?

## Summary `for` alone can express a counting loop, a while-loop (just a condition, no init/post), or an infinite loop (no clauses at all) — so a second keyword would just be redundant syntax for the same construct. ## Longer Answer `for` alone can express a counting loop, a while-loop (just a condition, no init/post), or an infinite loop (no clauses at all) — so a second keyword would just be redundant syntax for the same construct. This is consistent with Go's general design philosophy of minimizing the number of ways to express the same idea. In practice, explain where this shows up in production code, what tradeoffs matter, and how you would justify the choice in an interview. ## Key Points - `for` alone can express a counting loop, a while-loop (just a condition, no init/post), or an infinite loop (no clauses at all) — so a second keyword would just be redundant syntax for the same construct - This is consistent with Go's general design philosophy of minimizing the number of ways to express the same idea - In practice, explain where this shows up in production code, what tradeoffs matter, and how you would justify the choice in an interview - Use the answer to connect the concept back to a realistic production or interview scenario for 'Why does Go have only one looping keyword, `for`, instead of separate `while`/`do-while` constructs?' ## Comparison / Tradeoffs | Aspect | Notes | | --- | --- | | Core idea | `for` alone can express a counting loop, a while-loop (just a condition, no init/post), or an infinite loop (no clauses at all) — so a second keyword would just be redundant syntax for the same construct. | | Practical tradeoff | This is consistent with Go's general design philosophy of minimizing the number of ways to express the same idea. |

Q: How does an `if` statement's optional short initialization clause help write cleaner code?

## Summary It lets you scope a variable to just the if/else block — for example `if err := doThing(); err != nil { ... ## Longer Answer It lets you scope a variable to just the if/else block — for example `if err := doThing(); err != nil { ... }` — so the variable doesn't leak into the surrounding scope where it isn't needed. ## Key Points - It lets you scope a variable to just the if/else block — for example `if err := doThing(); err != nil { - }` — so the variable doesn't leak into the surrounding scope where it isn't needed - This pattern is idiomatic for error handling in Go — you'll see `if err := ...; err != nil` constantly in real Go code - Use the answer to connect the concept back to a realistic production or interview scenario for 'How does an `if` statement's optional short initialization clause help write cleaner code?' ## Comparison / Tradeoffs | Aspect | Notes | | --- | --- | | Core idea | It lets you scope a variable to just the if/else block — for example `if err := doThing(); err != nil { ... | | Practical tradeoff | This pattern is idiomatic for error handling in Go — you'll see `if err := ...; err != nil` constantly in real Go code. |

Declare data and control program execution

Variables, Types, and Control Flow

Go is statically typed but supports type inference with := for concise declarations inside functions. Basic types include int, float64, string, bool, and composite types like arrays, slices, and maps.

name := "Ada"        // inferred as string
var age int = 30      // explicit type
const Pi = 3.14159     // compile-time constant

Control Flow

Go has only one looping construct, for, which can act as a while-loop, an infinite loop, or a classic counting loop. if statements can include a short initialization statement, and switch cases do not fall through by default.

for i := 0; i < 5; i++ {
    if i%2 == 0 {
        fmt.Println(i, "is even")
    }
}

Practice questions

When would you use `:=` versus `var name Type = value`?

Answer

Summary

Longer Answer

:= is for concise declarations inside a function where the type can be inferred from the value; var is needed at package level, or when you want to be explicit about the type regardless of the initial value. := is shorthand only valid inside function bodies — package-level declarations must use var. In practice, explain where this shows up in production code, what tradeoffs matter, and how you would justify the choice in an interview.

Key Points

:= is for concise declarations inside a function where the type can be inferred from the value; var is needed at package level, or when you want to be explicit about the type regardless of the initial value
:= is shorthand only valid inside function bodies — package-level declarations must use var
In practice, explain where this shows up in production code, what tradeoffs matter, and how you would justify the choice in an interview
Use the answer to connect the concept back to a realistic production or interview scenario for 'When would you use := versus var name Type = value?'

Comparison / Tradeoffs

Aspect	Notes
Core idea	`:=` is for concise declarations inside a function where the type can be inferred from the value; `var` is needed at package level, or when you want to be explicit about the type regardless of the initial value.
Practical tradeoff	`:=` is shorthand only valid inside function bodies — package-level declarations must use `var`.

Why

Summary

:= is shorthand only valid inside function bodies — package-level declarations must use var.

Longer Answer

:= is shorthand only valid inside function bodies — package-level declarations must use var. In practice, explain where this shows up in production code, what tradeoffs matter, and how you would justify the choice in an interview.

Key Points

:= is shorthand only valid inside function bodies — package-level declarations must use var
In practice, explain where this shows up in production code, what tradeoffs matter, and how you would justify the choice in an interview
In an interview, relate 'When would you use := versus var name Type = value?' to implementation decisions, tradeoffs, and operational impact
Use the answer to connect the concept back to a realistic production or interview scenario for 'When would you use := versus var name Type = value?'

Comparison / Tradeoffs

Aspect	Notes
Core idea	`:=` is shorthand only valid inside function bodies — package-level declarations must use `var`.
Practical tradeoff	In an interview, relate 'When would you use `:=` versus `var name Type = value`?' to implementation decisions, tradeoffs, and operational impact.

Why does Go have only one looping keyword, `for`, instead of separate `while`/`do-while` constructs?

Answer

Summary

Longer Answer

for alone can express a counting loop, a while-loop (just a condition, no init/post), or an infinite loop (no clauses at all) — so a second keyword would just be redundant syntax for the same construct. This is consistent with Go's general design philosophy of minimizing the number of ways to express the same idea. In practice, explain where this shows up in production code, what tradeoffs matter, and how you would justify the choice in an interview.

Key Points

for alone can express a counting loop, a while-loop (just a condition, no init/post), or an infinite loop (no clauses at all) — so a second keyword would just be redundant syntax for the same construct
This is consistent with Go's general design philosophy of minimizing the number of ways to express the same idea
In practice, explain where this shows up in production code, what tradeoffs matter, and how you would justify the choice in an interview
Use the answer to connect the concept back to a realistic production or interview scenario for 'Why does Go have only one looping keyword, for, instead of separate while/do-while constructs?'

Comparison / Tradeoffs

Aspect	Notes
Core idea	`for` alone can express a counting loop, a while-loop (just a condition, no init/post), or an infinite loop (no clauses at all) — so a second keyword would just be redundant syntax for the same construct.
Practical tradeoff	This is consistent with Go's general design philosophy of minimizing the number of ways to express the same idea.

Why

Summary

This is consistent with Go's general design philosophy of minimizing the number of ways to express the same idea.

Longer Answer

This is consistent with Go's general design philosophy of minimizing the number of ways to express the same idea. In practice, explain where this shows up in production code, what tradeoffs matter, and how you would justify the choice in an interview.

Key Points

This is consistent with Go's general design philosophy of minimizing the number of ways to express the same idea
In practice, explain where this shows up in production code, what tradeoffs matter, and how you would justify the choice in an interview
In an interview, relate 'Why does Go have only one looping keyword, for, instead of separate while/do-while constructs?' to implementation decisions, tradeoffs, and operational impact
Use the answer to connect the concept back to a realistic production or interview scenario for 'Why does Go have only one looping keyword, for, instead of separate while/do-while constructs?'

Comparison / Tradeoffs

Aspect	Notes
Core idea	This is consistent with Go's general design philosophy of minimizing the number of ways to express the same idea.
Practical tradeoff	In an interview, relate 'Why does Go have only one looping keyword, `for`, instead of separate `while`/`do-while` constructs?' to implementation decisions, tradeoffs, and operational impact.

How does an `if` statement's optional short initialization clause help write cleaner code?

Answer

Summary

It lets you scope a variable to just the if/else block — for example `if err := doThing(); err != nil { ...

Longer Answer

It lets you scope a variable to just the if/else block — for example if err := doThing(); err != nil { ... } — so the variable doesn't leak into the surrounding scope where it isn't needed.

Key Points

It lets you scope a variable to just the if/else block — for example `if err := doThing(); err != nil {
}` — so the variable doesn't leak into the surrounding scope where it isn't needed
This pattern is idiomatic for error handling in Go — you'll see if err := ...; err != nil constantly in real Go code
Use the answer to connect the concept back to a realistic production or interview scenario for 'How does an if statement's optional short initialization clause help write cleaner code?'

Comparison / Tradeoffs

Aspect	Notes
Core idea	It lets you scope a variable to just the if/else block — for example `if err := doThing(); err != nil { ...
Practical tradeoff	This pattern is idiomatic for error handling in Go — you'll see `if err := ...; err != nil` constantly in real Go code.

Why

Summary

This pattern is idiomatic for error handling in Go — you'll see if err := ...; err != nil constantly in real Go code.

Longer Answer

This pattern is idiomatic for error handling in Go — you'll see if err := ...; err != nil constantly in real Go code. In practice, explain where this shows up in production code, what tradeoffs matter, and how you would justify the choice in an interview.

Key Points

This pattern is idiomatic for error handling in Go — you'll see if err := ...; err != nil constantly in real Go code
In practice, explain where this shows up in production code, what tradeoffs matter, and how you would justify the choice in an interview
In an interview, relate 'How does an if statement's optional short initialization clause help write cleaner code?' to implementation decisions, tradeoffs, and operational impact
Use the answer to connect the concept back to a realistic production or interview scenario for 'How does an if statement's optional short initialization clause help write cleaner code?'

Comparison / Tradeoffs

Aspect	Notes
Core idea	This pattern is idiomatic for error handling in Go — you'll see `if err := ...; err != nil` constantly in real Go code.
Practical tradeoff	In an interview, relate 'How does an `if` statement's optional short initialization clause help write cleaner code?' to implementation decisions, tradeoffs, and operational impact.

Open in the app to mark lessons complete, take notes and track your progress.