Indentation Style vs Brace Style: Two Layouts for the Same Verse

1. The Same Code, Two Layouts

Every code block in Verse can take one of two shapes: colon + newline + indentation, or braces { }. Several expressions inside a block can be separated by newlines or by semicolons ;. Start with the default, indentation style:

using { /Fortnite.com/Devices }
using { /UnrealEngine.com/Temporary/Diagnostics }

turret_device := class(creative_device):

    var Ammo:int = 3

    Fire():void =
        if (Ammo > 0):
            set Ammo -= 1
            Print("Fire, {Ammo} left")
        else:
            Print("Empty")

Same logic, with both branch bodies switched to braces and a semicolon separating the two things on one line:

using { /Fortnite.com/Devices }
using { /UnrealEngine.com/Temporary/Diagnostics }

turret_device := class(creative_device):

    var Ammo:int = 3

    Fire():void =
        if (Ammo > 0) { set Ammo -= 1; Print("Fire, {Ammo} left") }
        else { Print("Empty") }

13 lines became 10, and the behavior is identical. Note two details: first, once if takes braces you drop the colon — the colon and the braces occupy the same slot, and it's one or the other; second, the class body still uses a colon and indentation in both versions. Classes are written that way throughout the official docs, and braces earn their keep inside function bodies.

Can you brace all the way down? You can, but you won't enjoy the result:

    Fire():void = { if (Ammo > 0) { set Ammo -= 1; Print("Fire, {Ammo} left") } else { Print("Empty") } }

That line is legal and unreadable. Layout C exists here only as a reminder: what the language permits and what you should write are two different questions.

2. The One You Must Learn: One-Line if (X) { }

If you take one thing away from this page, take this. Open any Epic sample and you will run into lines like these:

        # "Do it if you can, never mind if you can't": braces deliberately empty
        if (set PlayerScores[Player] = 10) {}

        # "Use it if you can get it": check and fetch in one move
        if (First := Numbers[0]) { Print("The first one is {First}") }

Take it apart: a Verse if must carry a block, and in both of these situations there is nothing to do "after it passes" — the first writes a value into a table and is done; the second prints the value it managed to fetch. Written in indentation style, the first would take three lines (one for the if, one indented line with something in it). With braces, one empty pair of {} says the whole thing: "succeeded, and there's nothing else to do; didn't succeed, never mind."

Why this idiom matters: it is Verse's standard posture for "operations that might not go through" (writing into a map, indexing an array, unwrapping an option — all of them are this kind of operation). If you can't read if (…) {}, you can't read Epic's sample code — and in UEFN, sample code is the primary textbook for learning any API.

Incidentally, that empty {} is not special syntax sugar. It's an empty code block that produces no useful value — the same thing as dragging a wire out of a Branch's True pin in Blueprints and wiring no node to it.

3. When to Use Which

Three hard rules on top of that, each worth half an hour if you break it:

• One block, one style. You can't open with a colon and close with a brace. Pick one and carry it through.
• Indent with spaces only, 4 per level, never tabs. The realistic risk with indentation style isn't writing it wrong, it's pasting it wrong — copy a snippet out of a web page or a chat window and the indentation gets eaten or laced with tabs, and the compiler hands you a pile of baffling errors. After pasting, check that the indentation lines up.
• Semicolons only separate several expressions on one line. Verse doesn't want end-of-line semicolons; adding one out of habit just makes people think you're writing C#.

4. Settling On a House Rule

If your team is migrating over from Blueprints, nail down two things on day one:

1. Indentation style by default. Not because it looks better, but because the official docs, Epic's samples and the overwhelming majority of community code all use it — newcomers can copy it, search it, and get correct answers about it from an AI. Following the biggest body of existing material is always the cheap option.
2. Carve out one explicit exemption for braces: single lines only, and no more than two things on that line. Framing it as "an idiom" rather than "an alternative style" is what stops two layouts from fighting inside one file.

Why fuss over layout at all? Because this is precisely the dividend you collect by moving to text code. Blueprints are stored as binary assets: two people editing the same graph have to coordinate by talking, and the diff is essentially unreadable. A .verse file is plain text — it goes into Git, it can be code-reviewed, and an AI can read and edit it. But that dividend has a precondition: the diff must contain only real changes. In a repo where layout style flip-flops, every diff is laced with pure formatting noise, reviewers give up after the second one, and the dividend goes to zero on the spot.

Put plainly, layout rules aren't aesthetic fussiness. They exist so that "what actually changed this time" always has an answer you can get in five seconds. That was impossible in the Blueprint era no matter how much you wanted it; it's possible now, so don't throw it away yourself.

5. Quick Quiz

Sources

Compiled from Epic's official documentation and the official language book: Verse Language Quick Reference (official docs) ↗ · block expression (official docs) ↗ · Book of Verse — Control Flow (official language book) ↗