Skip to main content
This document outlines the code style rules for Firedancer. The code style is ultimately defined by the code in src/tango.
Most contributors do not use a code formatting tool. The Firedancer codebase uses a distinctive style that emphasizes readability through vertical alignment.

General Guidelines

Text Word Wrap

Aspire to word wrap text (comments, not code) at 72 columns for readability. After accounting for the indent, this is right around the level the publishing industry has used for hundreds of years for making print easily readable with minimal eye strain.

Repository Organization

  • See doc/organization.txt for detailed organization guidelines
  • Avoid cluttering the repository root

File Extensions

Include Guards

Header files must use #ifndef include guards. Never use #pragma once. Given file: src/path/to/file/fd_file_name.h:

Vertical Alignment

Popular code formatting tools would produce compact but less readable code. Firedancer uses vertical alignment for better readability.

Spacing Rules

Function Calls

Zero arguments: No spaces inside brackets
With arguments: Spaces inside brackets, no space before brackets
Exception for sizeof: Usually no spaces
Exception for double bracket macros: No spaces between brackets

Control Flow

Annotate uncommon error paths with FD_UNLIKELY. Single-line statements: No braces required
Multi-line statements: Braces are mandatory
Spacing: Spaces in brackets, no spaces before brackets

Function Prototypes

  • Modifiers and return types on separate lines
  • One function argument per line
  • Vertically align function argument types and names

Type System

Integers

Use fd_util_base.h types instead of stdint.h integer types.
For more information on why Firedancer uses custom integer types, see src/util/fd_util_base.h and doc/rant/integer-types.md.

Booleans

Do not use bool (stdbool). Instead use int.
  • 1 is “true”
  • 0 is “false”

Function Documentation

  • Documentation goes before the function prototype in a comment block
  • Comments should mention the function name toward the beginning
  • Public API functions must be documented
  • Implementations must not repeat the comment

Macros

Enclose Arguments in Braces

Use do/while(0) Scopes

Evaluate Arguments Only Once

Portability

Build Capabilities

Firedancer aspires to compile under any LP64 environment. Components with additional assumptions should check for capabilities via FD_HAS_{...} switches. Example Makefile:
Example C code:

Language Features

Stick to ISO C17. GNU C extensions are permitted as long as they are well supported by Clang and CBMC.

seccomp Sandbox

Firedancer uses a strict sandbox architecture on Linux platforms using seccomp.
During initialization, a seccomp profile is installed to each tile containing rules for allowed syscalls. If a syscall is triggered unexpectedly, seccomp will crash Firedancer.Be mindful of what syscalls glibc could use under the hood when using standard library APIs. Note that syscalls used can differ between glibc versions.

File I/O

Prefer fd_io over stdio.h for streaming file I/O. Make sure to handle EINTR correctly.

Security Best Practices

Complex Function Exit

For functions with complex control flow that need cleanup, use a do/while scope:
For resource cleanup, you may use the cleanup attribute:
For better readability, wrap the cleanup attribute in macros. See FD_SCRATCH_SCOPE_BEGIN in src/util/scratch/fd_scratch.h.