Control Structures

The Infinite Loop That Wasn't

My fourth day writing Go, I deployed code to staging that immediately crashed:

func processQueue() {
    for {
        item := queue.Pop()
        if item == nil {
            break
        }
        process(item)
    }
}

The queue was empty. queue.Pop() returned nil. The loop broke immediately. In production, this would have stopped processing forever once the queue drained.

Coming from Python's while True:, I didn't understand Go's for loop nuances. The fix required understanding Go's approach to control structures - which is both simpler and more powerful than I expected.

This article covers the control flow lessons I learned by breaking things in staging.

---

The for Loop: Go's Only Loop

Go has one loop construct: for. No while, no do-while, no foreach. Just for.

This seemed limiting until I realized for does everything.

Traditional For Loop

// Classic three-component loop
for i := 0; i < 10; i++ {
    fmt.Println(i)
}
// 0 1 2 3 4 5 6 7 8 9

Components:

1. Init: i := 0 (executed once)

2. Condition: i < 10 (checked before each iteration)

3. Post: i++ (executed after each iteration)

While-style Loop

// While equivalent - just use condition
i := 0
for i < 10 {
    fmt.Println(i)
    i++
}

Infinite Loop

// Infinite loop - just use 'for'
for {
    // Runs forever
    // Use break to exit
}

This is where my queue processor failed. The pattern should have been:

func processQueue() {
    for {
        item := queue.Pop()
        if item == nil {
            time.Sleep(100 * time.Millisecond)
            continue  // Keep polling, don't break!
        }
        process(item)
    }
}

Range Loop (foreach equivalent)

// Iterate over slice
numbers := []int{1, 2, 3, 4, 5}
for index, value := range numbers {
    fmt.Printf("Index: %d, Value: %d\n", index, value)
}

// Ignore index with _
for _, value := range numbers {
    fmt.Println(value)
}

// Just need index
for i := range numbers {
    fmt.Println(i)
}

// Iterate over map
users := map[string]int{
    "Alice": 25,
    "Bob":   30,
}
for name, age := range users {
    fmt.Printf("%s is %d years old\n", name, age)
}

// Iterate over string (runes, not bytes!)
for i, char := range "Hello 世界" {
    fmt.Printf("Position %d: %c\n", i, char)
}

Range gotcha that bit me:

// DON'T DO THIS
numbers := []int{1, 2, 3}
for _, n := range numbers {
    go func() {
        fmt.Println(n)  // BUG: All goroutines see same 'n'!
    }()
}
time.Sleep(time.Second)
// Prints: 3 3 3

// CORRECT: Pass value to goroutine
for _, n := range numbers {
    n := n  // Create new variable
    go func() {
        fmt.Println(n)
    }()
}
// Prints: 1 2 3 (in some order)

---

Break and Continue

Break: Exit Loop

for i := 0; i < 10; i++ {
    if i == 5 {
        break  // Exit loop when i is 5
    }
    fmt.Println(i)
}
// 0 1 2 3 4

Continue: Skip to Next Iteration

for i := 0; i < 10; i++ {
    if i%2 == 0 {
        continue  // Skip even numbers
    }
    fmt.Println(i)
}
// 1 3 5 7 9

Labels: Break from Nested Loops

Real code from my CSV processor:

// Process CSV until we find target row
outer:
for _, row := range rows {
    for _, cell := range row {
        if cell == targetValue {
            fmt.Println("Found it!")
            break outer  // Exit both loops
        }
    }
}

// Without label, break only exits inner loop
for _, row := range rows {
    for _, cell := range row {
        if cell == targetValue {
            break  // Only exits inner loop
        }
    }
}

---

If Statements

Basic If

if x > 10 {
    fmt.Println("x is large")
}

// No parentheses required (they're allowed but not idiomatic)
// Braces are mandatory

If-Else

if x > 10 {
    fmt.Println("x is large")
} else {
    fmt.Println("x is small")
}

If-Else If

if score >= 90 {
    grade = "A"
} else if score >= 80 {
    grade = "B"
} else if score >= 70 {
    grade = "C"
} else {
    grade = "F"
}

If with Initialization (Powerful!)

This is a Go feature I use constantly:

// Scope variable to if block
if err := doSomething(); err != nil {
    return err
}
// err not accessible here

// Before (verbose)
err := doSomething()
if err != nil {
    return err
}
// err still in scope (pollutes namespace)

Real example from my file processor:

if data, err := os.ReadFile("config.json"); err != nil {
    return fmt.Errorf("failed to read config: %w", err)
} else {
    // Parse data
    var config Config
    if err := json.Unmarshal(data, &config); err != nil {
        return fmt.Errorf("failed to parse config: %w", err)
    }
    // Use config
}

This keeps variables scoped tightly and prevents namespace pollution.

---

Switch Statements

Go's switch is more powerful than C/Java switch - no fall-through by default!

Basic Switch

switch day {
case "Monday":
    fmt.Println("Start of work week")
case "Friday":
    fmt.Println("TGIF!")
case "Saturday", "Sunday":
    fmt.Println("Weekend!")
default:
    fmt.Println("Regular day")
}

No break needed! Each case automatically breaks.

Switch with Initialization

switch day := time.Now().Weekday(); day {
case time.Monday:
    fmt.Println("Monday blues")
case time.Friday:
    fmt.Println("Friday feeling")
default:
    fmt.Println("Regular day")
}

Expression-less Switch (like if-else chain)

This is incredibly useful:

score := 85

switch {
case score >= 90:
    grade = "A"
case score >= 80:
    grade = "B"
case score >= 70:
    grade = "C"
default:
    grade = "F"
}

Real example from my request router:

switch {
case r.Method == "GET" && r.URL.Path == "/health":
    handleHealth(w, r)
case r.Method == "POST" && strings.HasPrefix(r.URL.Path, "/api/"):
    handleAPI(w, r)
case r.Method == "GET":
    handleStatic(w, r)
default:
    http.NotFound(w, r)
}

Much cleaner than nested if-else!

Type Switch

For working with interfaces (we'll cover interfaces in detail later):

func process(value interface{}) {
    switch v := value.(type) {
    case int:
        fmt.Printf("Integer: %d\n", v)
    case string:
        fmt.Printf("String: %s\n", v)
    case bool:
        fmt.Printf("Boolean: %t\n", v)
    default:
        fmt.Printf("Unknown type: %T\n", v)
    }
}

process(42)        // Integer: 42
process("hello")   // String: hello
process(true)      // Boolean: true

Fall-through (explicit)

If you need C-style fall-through, use fallthrough:

switch n := 2; n {
case 1:
    fmt.Println("One")
    fallthrough
case 2:
    fmt.Println("Two")
    fallthrough
case 3:
    fmt.Println("Three")
}
// Output:
// Two
// Three

I've used fallthrough exactly once in production. It's rare.

---

The defer Statement

defer schedules a function to run when the surrounding function returns. This is one of Go's most elegant features.

Basic Defer

func readFile(filename string) error {
    file, err := os.Open(filename)
    if err != nil {
        return err
    }
    defer file.Close()  // Runs when function returns
    
    // Do stuff with file
    // Don't worry about closing - defer handles it
    data := make([]byte, 1024)
    file.Read(data)
    
    return nil
}  // file.Close() called here automatically

Multiple Defers (LIFO order)

func demo() {
    defer fmt.Println("First")
    defer fmt.Println("Second")
    defer fmt.Println("Third")
    
    fmt.Println("Regular")
}

// Output:
// Regular
// Third
// Second
// First

Defers execute in Last-In-First-Out order (like a stack).

Real-World Usage: Resource Management

Database transactions:

func updateUser(db *sql.DB, userID int, name string) error {
    tx, err := db.Begin()
    if err != nil {
        return err
    }
    defer tx.Rollback()  // Rollback if we don't commit
    
    _, err = tx.Exec("UPDATE users SET name = ? WHERE id = ?", name, userID)
    if err != nil {
        return err  // Deferred rollback happens
    }
    
    return tx.Commit()  // Commit overrides rollback
}

Mutex unlocking:

func (c *Counter) Increment() {
    c.mu.Lock()
    defer c.mu.Unlock()  // Always unlock, even on panic
    
    c.value++
}

Timing functions:

func slowOperation() {
    defer func(start time.Time) {
        fmt.Printf("Operation took %v\n", time.Since(start))
    }(time.Now())  // Capture start time immediately
    
    // Do slow work
    time.Sleep(2 * time.Second)
}
// Output: Operation took 2.001s

Defer Gotcha: Loop Variables

This bug cost me an hour:

// WRONG
files := []string{"file1.txt", "file2.txt", "file3.txt"}
for _, filename := range files {
    f, _ := os.Open(filename)
    defer f.Close()  // BUG: All defers wait until function returns!
}
// Opens all files, closes none until function ends

// CORRECT
for _, filename := range files {
    func() {
        f, _ := os.Open(filename)
        defer f.Close()  // Closes at end of this function
        // Process file
    }()
}

In the first version, all files stay open until the parent function returns (file descriptor leak!).

---

Practical Example: Request Retry Logic

Real code from my API client:

func (c *Client) makeRequest(url string, maxRetries int) (*Response, error) {
    var lastErr error
    
    for attempt := 0; attempt <= maxRetries; attempt++ {
        // Log attempt
        if attempt > 0 {
            wait := time.Duration(attempt) * time.Second
            fmt.Printf("Retry %d/%d after %v\n", attempt, maxRetries, wait)
            time.Sleep(wait)
        }
        
        resp, err := http.Get(url)
        if err != nil {
            lastErr = err
            continue  // Try again
        }
        defer resp.Body.Close()
        
        // Check status
        switch {
        case resp.StatusCode == 200:
            return c.parseResponse(resp)
        case resp.StatusCode >= 500:
            lastErr = fmt.Errorf("server error: %d", resp.StatusCode)
            continue  // Retry on server error
        default:
            return nil, fmt.Errorf("client error: %d", resp.StatusCode)
        }
    }
    
    return nil, fmt.Errorf("max retries exceeded: %w", lastErr)
}

This uses:

• for with counter

• if with initialization

• switch for status codes

• defer for resource cleanup

• continue for retries

---

Common Patterns

Safe Integer Parsing

if num, err := strconv.Atoi(input); err != nil {
    return fmt.Errorf("invalid number: %w", err)
} else if num < 0 {
    return fmt.Errorf("number must be positive")
} else {
    return processNumber(num)
}

Early Return Pattern

func validate(user *User) error {
    if user == nil {
        return errors.New("user is nil")
    }
    if user.Email == "" {
        return errors.New("email required")
    }
    if user.Age < 18 {
        return errors.New("must be 18+")
    }
    return nil
}

Exponential Backoff

func retryWithBackoff(operation func() error, maxRetries int) error {
    for attempt := 0; attempt < maxRetries; attempt++ {
        err := operation()
        if err == nil {
            return nil
        }
        
        if attempt == maxRetries-1 {
            return err
        }
        
        backoff := time.Duration(1<<uint(attempt)) * time.Second
        fmt.Printf("Retry in %v\n", backoff)
        time.Sleep(backoff)
    }
    return nil
}

---

Your Challenge

Build a simple game: Guess the number

package main

import (
    "fmt"
    "math/rand"
    "time"
)

func main() {
    rand.Seed(time.Now().UnixNano())
    target := rand.Intn(100) + 1
    
    // Your code here:
    // 1. Loop until user guesses correctly
    // 2. Read user input
    // 3. Give hints (higher/lower)
    // 4. Count attempts
    // 5. Congratulate on success
}

Bonus: Add difficulty levels, max attempts, play again logic.

---

Key Takeaways

1. One loop to rule them all: for does everything

2. Range is powerful: Clean iteration over collections

3. If with init: Scope variables tightly

4. Switch without fall-through: No break needed by default

5. Expression-less switch: Better than if-else chains

6. Defer for cleanup: Resources close automatically

7. Defer is LIFO: Last deferred executes first

---

What I Learned

The simplicity of Go's control structures is deceptive. Having only for seemed limiting until I realized:

• No confusion about for vs while vs foreach

• Switch without fall-through prevents bugs

• Defer makes resource management bulletproof

• If with initialization keeps code clean

The queue bug taught me to think differently about loops. In Python, I'd write while True. In Go, I write for { } and think about the exit conditions more carefully.

---

Next: Functions and Methods

In the next article, we'll explore Go's approach to functions: multiple return values, named returns, methods on types, and how functions are first-class citizens. You'll see how this changes the way you structure code.