Guard clause

A locked door should say no quickly. Door.Enter checks three reasons to stop, then leaves the successful route free of extra nesting.

The problem

The goal receives trigger callbacks more than once. It must ignore a missing player, refuse entry while locked, and do nothing after completion. Only a valid first entry should finish the level.

When to reach for it

• Invalid input should stop the method before any state changes.
• A repeated callback must be harmless.
• The successful route is easier to read when exceptions leave early.

See it

Figure 1. Each true guard route reaches a return; the final route performs completion work.

The current Platformer source is:

C#

public void Enter(PlayerController player)
{
    if (player == null)
    {
        return;
    }

    if (!IsUnlocked)
    {
        _logger?.Log("player reached the goal, but it is still locked.");
        return;
    }

    if (IsCompleted)
    {
        return;
    }

    IsCompleted = true;
    _hud?.RefreshComplete();
    _audio?.PlayCompletion();
    player.gameObject.SetActive(false);
    _logger?.Log("goal reached: level complete.");
}

Do it

1. Open Door in Graph View and select Enter.

2. Start at the entry node. Follow the first white exec wire into the player == null branch. Its true output reaches return immediately.

3. Follow the false output to !IsUnlocked. Its true route logs why entry failed, then returns. The log belongs to this guard because it explains a normal player action.

4. Continue from false to IsCompleted. Its true route returns with no work. Repeated trigger calls after completion should stay quiet.

5. Follow the last false output. This is the only route that sets IsCompleted, refreshes the HUD, plays audio, disables the player, and logs completion.

You should see

You can read the graph as three stop signs followed by one straight success route. Every completion call happens after every guard.

Change one thing

Trace backward from player.gameObject.SetActive(false). You should cross the false output of all three guards. If any route reaches that call without those checks, the method no longer has the same safety shape.

What it writes

Adding one more guard for an inactive player would add one branch and one return before the completion statements:

C#

What it writes

C#

if (!player.isActiveAndEnabled)
{
    return;
}

The existing checks remain separate. Combining every reason into one long condition would hide which guard owns the locked-door message.

Round Trip also reads the plainest shape on class state as a guard. A bare if (!_isConfigured) return; at the top of a method, on a bool field or property, is listed in the method’s Guards card as a guard on that bool, and its style editor is headed “If _isConfigured is false…”. Edits made in that card wait for the toolbar Compile; the card’s own banner offers only Discard. !IsUnlocked in Door.Enter is not read this way, because its route logs before it returns, so it stays an ordinary branch.

When it goes wrong

When it goes wrong

Symptom	Check	Fix
Completion calls still run for a missing player.	Follow the true output of player == null.	Connect that output to a return before the completion sequence.
The locked message appears after completion.	Read the order of the locked-state and completed-state guards.	Keep each message on the route whose condition it explains.
The success route is deeply nested.	Count branches that wrap the final statements instead of returning.	Send rejected cases to return and leave the successful route on false.

Next

• Branch: read true and false outputs.
• Return and throw: end a route explicitly.
• Method calls: inspect the completion calls after the guards.