Editors, LSP, and Debuggers

You can write Zig code in any text editor.

A Zig source file is plain text. It usually ends with:

.zig

For example:

main.zig

You do not need a special IDE to learn Zig. A simple editor and a terminal are enough. But a good editor setup makes learning easier because it can show errors, format code, and help you move around a project.

The Basic Setup

For this book, you need three things:

The editor is where you write code.

The terminal is where you run commands such as:

zig run main.zig
zig test main.zig
zig fmt main.zig
zig build

The compiler checks and builds your code.

Choosing an Editor

Common choices include:

For absolute beginners, VS Code is often the easiest place to start.

For terminal users, Neovim, Helix, or Emacs are also good choices.

The editor does not change the Zig language. Choose the tool you can use comfortably.

What an LSP Is

LSP means Language Server Protocol.

That sounds complicated, but the idea is simple.

An LSP server is a program that helps your editor understand your code.

With Zig, the common language server is called ZLS, short for Zig Language Server.

An editor plus ZLS can provide features such as:

Without LSP, your editor is mostly editing text.

With LSP, your editor understands more about the program.

Installing ZLS

ZLS is usually installed separately from Zig.

Your editor extension may help install it, or you may install it manually.

The exact method depends on your system and editor. The important point is this:

Zig compiler and ZLS should match closely.

If your Zig compiler is version 0.16.x, use a ZLS version intended for that Zig version.

If ZLS and Zig are mismatched, you may see strange editor errors even when the program builds correctly.

VS Code Setup

A typical VS Code setup is:

1. install Zig
2. install a Zig extension
3. install or configure ZLS
4. open your project folder
5. edit files under src/

After setup, VS Code should recognize .zig files.

When you open a file like:

src/main.zig

you should get syntax highlighting and language features.

A small test file:

const std = @import("std");

pub fn main() void {
    std.debug.print("Hello from editor setup!\n", .{});
}

Run it from the terminal:

zig run src/main.zig

If that works, your compiler is installed correctly.

If your editor also shows Zig syntax colors and helpful errors, your editor setup is working too.

Formatting Code

Zig includes an official formatter.

You can format a file manually:

zig fmt src/main.zig

Many editors can run this automatically when you save the file.

This is useful because Zig code has a standard style. You do not need to spend time deciding indentation rules.

For example, messy code like this:

pub fn main(  ) void{
}

becomes:

pub fn main() void {}

Use the formatter early. It keeps your examples clean and easier to compare with the book.

Reading Errors in the Editor

A good editor may show compiler or language-server errors inline.

For example:

const age: u32 = "hello";

This is wrong because age is declared as a number, but "hello" is text.

The editor may underline the error before you even run the program.

That is helpful, but remember: the compiler is the final authority.

If your editor says something is wrong but zig build succeeds, your editor or ZLS may be misconfigured.

If zig build fails, trust the compiler error.

Debuggers

A debugger lets you pause a running program and inspect it.

With a debugger, you can:

Zig can work with native debuggers such as LLDB and GDB.

The common choices are:

For beginners, you do not need to start with a debugger immediately. You can learn a lot with std.debug.print.

But as programs grow, a debugger becomes useful.

Debug Builds

Debuggers work best with debug builds.

By default, Zig builds in debug mode.

For example:

zig build-exe main.zig

This keeps debug information and safety checks.

An optimized release build like this:

zig build-exe main.zig -O ReleaseFast

may be harder to debug because the compiler changes the program to make it faster.

Variables may disappear. Lines may not execute in the exact order you expect. Some functions may be inlined.

While learning, use debug mode.

Print Debugging

The simplest debugging tool is printing values.

Example:

const std = @import("std");

pub fn main() void {
    const a = 10;
    const b = 20;
    const result = a + b;

    std.debug.print("a = {}, b = {}, result = {}\n", .{ a, b, result });
}

Output:

a = 10, b = 20, result = 30

This is not fancy, but it is effective.

When a program behaves incorrectly, print the values near the problem. Check whether the program’s state matches what you expected.

Compiler First, Editor Second

Do not depend completely on editor features.

Always know how to run the compiler yourself:

zig build

or:

zig run src/main.zig

This matters because editor tools can be stale, misconfigured, or using the wrong Zig version.

The command line gives you the clearest ground truth.

A Good Beginner Workflow

A simple workflow looks like this:

Do not try to fix ten errors at once.

Often, one syntax mistake causes several later errors. Fix the first error, then compile again.

What You Should Remember

You can write Zig in any editor.

A good setup includes syntax highlighting, ZLS, formatting, and a terminal.

ZLS helps your editor understand Zig code, but the Zig compiler is still the final authority.

Use zig fmt to keep code clean.

Use debug builds while learning.

Use std.debug.print first, then learn a debugger when your programs become larger.