Community / Community and Contributions

Code Style Guide

Native C++ formatting conventions for contributors with access to the relevant Trace repository.

This guide covers native C++ conventions derived from KiCad, not every Trace repository or language. Confirm access and contribution terms first; see Contributing.

Follow the owning repository

Read its contribution/build instructions and formatter configuration. The native repository's _clang-format is the formatting reference; do not assume custom Git formatting commands or hooks exist in your checkout.

Use the formatter version requested by the repository. Review formatting changes and limit them to the intended files/hunks. Do not bypass checks to hide an unexplained failure.

Native C++ formatting

The native configuration uses:

  • Four-space indentation, no tabs.
  • Eight-space continuation and constructor-initializer indentation.
  • A 120-character column limit.
  • Allman braces on their own lines.
  • Spaces inside nonempty parentheses, no space before them.
  • Pointer/reference markers attached to the type.
  • Existing include order; automatic sorting is disabled.

Use braces for control-flow bodies and match nearby established style.

class VALUE_HOLDER
{
public:
    void SetValue( int aValue )
    {
        m_value = aValue;
    }

private:
    int m_value = 0;
};

Naming and comments

Follow local naming conventions: native classes commonly use UPPER_SNAKE_CASE, public methods use descriptive PascalCase, member fields use m_, and parameters commonly use an a prefix. Do not rename unrelated existing code merely to impose a style.

Explain non-obvious invariants and failure behavior rather than restating the code. Document public interfaces, including ownership and meaningful return values. Keep required copyright/license notices.

Review and testing

Formatting is not correctness. Compile affected native targets, test normal and failure paths, and check platform-specific behavior when changing paths, threads, file ownership or UI lifetimes. Report untested platforms explicitly.

For web, Python or SDK changes, use that repository's own lint/test configuration instead of applying native C++ rules.

See the KiCad Code Style Policy for upstream context; the owning checkout's current guidance takes precedence for the contribution being reviewed.