Tactility/CODING_STYLE_CPP.md
Ken Van Hoeylandt d551e467b8
Moved and renamed files for consistent C code style (#463)
* **Documentation**
  * Added new C coding style guide detailing naming conventions for files, directories, macros, constants, variables, functions, and type definitions with illustrative examples.
  * Updated C++ coding style documentation with clarifications on C naming conventions and header directory organization patterns.

* **Refactor**
  * Updated header include paths throughout the codebase to use lowercase naming conventions consistently.
2026-01-27 20:17:33 +01:00

1.7 KiB

C++ coding Style

The basic formatting rules are set in .clang-format. Use auto-formatting in your editor.

All code should target C++ language revision 20.

If you use CLion, please enable the setting called "Enable ClangFormat" under Settings > Editor > Code Style.

C projects with C++ code

In projects that expose a C API with internal C++ code, the C naming conventions are used for language features that are shared.

Naming

Files

Files are upper camel case.

  • Files: ^[0-9a-zA-Z]+$
  • Directories: ^[0-9a-zA-Z]+$

Example:

SomeFeature.cpp
SomeFeature.h

Private/internal headers are placed in a Private/ directory.

Folders

Project folders include:

  • Source for source files and public header files
  • Private for private header files
  • Include for projects that require separate header files

Sources for a specific namespace must go into a folder with the lowercase name of that namespace. The only exception to this is the root namespace, as this doesn't require its own subfolder.

Function names

Names are lower camel case.

Example:

void getLimit() {
    // ...
}

Type names

Consts are lower camel case with capital letters.

Typedefs for structs, classes and datatype aliases are upper camel case.

Examples:

typedef uint32_t ThreadId;

const ThreadId id;

struct ThreadData {
    // ...
};

Enumerations

enum class or enum struct is preferred over plain enum because of scoping. It's styled like this:

enum class SomeType {
    Ok,
    NotSupported,
    Error
};

Exceptions

Don't ever throw them. Make a return type that wraps all the error and success scenarios that are relevant.