Conditionals with if and else

Coming from C, Java, or Python, your fingers want to write three things Go does not accept:

if count { }             // compile error — count is an int, not a bool
if (count > 0) { }       // compiles, but the parentheses are noise
count = f()
if count > 0 { }         // fine — but see below for what Go uses instead

The first rejection defines Go's conditional philosophy: a condition must be a boolean expression. There is no truthiness — 0 is not false, "" is not false, a nil pointer is not false. Where C would silently take the else branch for an empty string, Go refuses to compile the guess. The price is verbosity (if s != "" instead of if s); the payoff is that every branch's intent survives translation, and no reader has to remember which values their language considers falsy.

Parentheses are not part of the syntax — if, for, and switch never require them — and while if (a > b) parses, gofmt leaves your redundancy in place and every other Go file in the repo writes the bare form. Braces, conversely, are mandatory even for single statements. The reason is mechanical and worth knowing: Go inserts semicolons at newlines after closing tokens, so a brace dropped to its own line after ) or a condition turns into a syntax error. "Opening brace on the declaration line" is the compiler enforcing consistency, not a style guide.

The second rejection is subtler. In C, if (err = f()) — a single = that assigns and tests at once — is a legendary source of bugs. Go's grammar eliminates it by construction: assignments (=, :=, ++) are statements, not expressions, so they cannot appear where a condition's expression is expected. The compiler never has to warn you about it. What Go offers instead is better — an init statement that runs the call, binds the result, and tests it, all scoped to the branch — and that is the shape error handling in this language is built on.

So the vocabulary of a Go condition is exactly the operators from Operators and Expressions: comparisons, logical connectives with short-circuit guards, and nothing else. if u != nil && u.Active && len(u.ID) > 0 is the complete idiom — three facts, one line, ordered so the unsafe access only runs behind its guard. Everything beyond that belongs to the init statement.

The most common conditional in Go code does not test a variable that already exists — it fetches a value and tests that:

if user, ok := cache.Get(id); ok {
	return user, nil
}
// user is NOT in scope here — the declaration lived inside the if
return loadFromDB(id)

Syntax: if <statement>; <condition> {. The statement before the semicolon runs first, its declarations bind, then the condition is evaluated — and the declared names are scoped to the if body and its else body, disappearing entirely after the statement. That scoping is the feature. The value you fetched under a validity check cannot be read on a path where the check failed, because the name does not exist there.

It kills two bug classes at once. The C shape — declare above, forget to check, use anyway — becomes impossible: there is no "above." And the sprawling shape — fetch, then a separate if err != nil, then use — collapses into one readable line where cause and effect cannot be separated by a hundred lines of edits. The two canonical forms:

// map lookup with the presence flag
if v, ok := m[key]; ok {
	fmt.Println("found", v)
}

// error from a call, the backbone of Go error handling
if f, err := os.Open(path); err != nil {
	return fmt.Errorf("open %s: %w", path, err)
} else {
	defer f.Close()
}

(The else above is legal but discouraged — you will see the flattened version in a moment. The point is the shape: the call, the check, and the branch are one unit.)

The trap to internalize now is shadowing. Because each init statement declares its own names, this code compiles while logging the wrong error:

var err error
if resp, err := client.Get(url); err != nil {   // NEW err, scoped to this if
	log.Println(err)
	return err
}
fmt.Println(err)   // the OUTER err — still nil — not the one just checked

There is no bug in the if; the bug is assuming the init declaration wrote through to an outer err of the same name. := in an init position always declares inside the statement's scope (at least one new name is required, and resp is new). The defensive habits: declare close to use so only one err is visible at any point, and if you see two live errs in nested scopes, rename or flatten until there is one. This exact idiom — if err := ...; err != nil — is the contract shape in The error Interface and Error Messages, so the scoping rule is worth making automatic now.

Here is a permission check written the way the shape arrives in most people's heads:

func canView(user User, doc Doc) bool {
	if user.LoggedIn {
		if doc.Owner == user.ID {
			return true
		} else {
			if doc.Public {
				return true
			} else {
				if user.IsAdmin {
					return true
				} else {
					return false
				}
			}
		}
	}
	return false
}

Every added condition costs an indentation level, and after three levels the reviewable logic — the actual rules — is buried in whitespace. The rewrite applies one principle: handle the failure cases first and return, so the success path runs down a flat page.

func canView(user User, doc Doc) bool {
	if !user.LoggedIn {
		return false
	}
	if doc.Owner == user.ID || doc.Public || user.IsAdmin {
		return true
	}
	return false
}

Same behavior, half the lines, and each rule is scannable in isolation. Two supporting rules keep it honest. First, else after a return (or break/continue) is dead weight — the branch can never run, so the braces buy nothing:

if err != nil {
	return err
}
// no 'else' needed — nothing below runs on the error path
return process(doc)

Second, the compiler agrees: unreachable code after return is precisely what go vet's analysis flags, so the redundant form does not merely read worse, it invites a diagnostic.

When is else earned? When both branches assign a single value and neither returns — a two-way choice reads as one decision rather than two guards:

var status string
if resp.StatusCode >= 400 {
	status = "error"
} else {
	status = "ok"
}

(Or use the operators topic's constraint — there is no ternary in Go, so this is the idiom.) And three or more branches dispatching on one value is no longer an if/else if chain at all: switch Statements exists for exactly that, with none of the nesting and none of the repeated ==.

The judgment to carry forward: an if with an else inside an if inside an else is a signal, not a structure. Flatten with guards while the function still fits on a screen; beyond four or five conditions, the answer is a switch, a table, or a function — all covered as this roadmap moves from branching to dispatch.