Code style

The base is the Linux kernel standard, written in C++. C++ is used where it earns its keep — MLIR interop, standard containers, templates for speed — but the shape of the code stays C: plain structs and free functions, not object hierarchies.

Style is enforced by review, not by a formatter. This page mirrors STYLE.md in the repository root; if the two ever disagree, the file wins.

Files and headers

• Headers carry the project license block (SPDX-License: AGPL-3.0+, Copyright (c) SASS2MLIR Contributors), an include guard (COMMON_DISASSEMBLER_PARSER_H for common/disassembler/parser.h), and declarations.
• Indentation is 4 spaces; braces are K&R.
• File-local functions and variables are static. Anonymous namespaces are not used.

Plain structs, free functions

• Types are plain structs with public members and default initializers; behaviour lives in free functions that take the struct — parse_cubin, print_inst, pool_start. No classes with access sections, no member function APIs, no RAII ownership wrappers.
• Names are snake_case: sass_thread_pool, parse_line, pool_work.
• Struct members are documented with a trailing //!< comment.

Declarations ahead of use

Declarations come ahead of use, in every scope:

• File scope — types and objects are declared before the functions that use them.
• Function scope — trivial early-outs first, then the locals, then the work. Initializers may call functions; a local whose value is not ready yet is declared at the top and assigned later.
• Loop scope — the loop body’s locals sit at the top of the body, before its statements.

int nv_open(int32_t major, uint16_t minor, const char* path)
{
    if (major == -1)
        return -1;

    int fd = -1;
    dev_t dev = MAKE_DEV(major, minor);
    uid_t uid = get_param(proc_path, "DeviceFileUID");

    if (!device_exists(path))
        ...
}

Documentation lives in doc blocks

• Functions are documented above their definition (/*! \brief ... */ on APIs); this is where non-obvious behaviour rules belong.
• Comments inside a function body only in really rare situations when absolutely needed. If a rule needs explaining, it almost always belongs in the function’s doc block instead.

Control flow and small rules

• goto is fine where it is the natural control flow — shared cleanup, loop-continue tails. Do not contort the structure to avoid it.
• Single-statement conditionals go without braces: if (fp == nullptr) return false;
• Aggregate-style zeroing is written = {}; — e.g. sass_operand op = {};