libmyrtx C99 Development Standards
Enforce strict C99 coding standards for the libmyrtx library, focusing on memory safety, consistent naming, comprehensive documentation, and test coverage.
Code Style & Standards
C99 Compliance
**Scope**: All `.c` and `.h` filesEnsure all C code strictly adheres to C99 standardsUse C99-specific features where appropriate (inline, restrict, designated initializers)Header Guard Convention
**Pattern**: `MYRTX_MODULE_FILENAME_H`All header files must use this standardized guard patternExample: `src/core/allocator.h` → `#ifndef MYRTX_CORE_ALLOCATOR_H`Documentation Requirements
**Scope**: All public functions in `.c` and `.h` filesEvery public function must have a documentation comment blockInclude description, parameters, return value, and any side effectsAll comments and documentation must be written in **English** (even though team communication is in German)Memory Management
**Scope**: All `.c` filesPrefer the arena allocator for memory allocation wherever possibleAvoid direct use of `malloc()` and `free()`Document any exceptions to this ruleError Handling
**Scope**: All `.c` filesUse the libmyrtx context system for error propagationAvoid raw error codes or errno-based handlingEnsure errors are properly logged and handled at appropriate layersNaming Convention
**Pattern**: `myrtx_module_function`All public functions must follow this snake_case naming patternModule name should reflect the subsystem (e.g., `myrtx_arena_alloc`, `myrtx_context_set_error`)Private/static functions may use single underscore prefix (e.g., `_internal_helper`)Test Coverage
**Scope**: All source files under `src/`Each source file should have corresponding unit testsTest files should mirror the source structure (e.g., `src/core/allocator.c` → `tests/core/test_allocator.c`)Aim for high code coverage, especially for critical pathsIndentation & Formatting
**Tab Type**: Hard tabs (not spaces)**Tab Width**: 4 spaces**Line Endings**: LF (Unix-style)Enable "Format on Save" in your editorDocumentation Maintenance
**Scope**: All `.rst` files (Sphinx/reStructuredText documentation)Documentation must always be kept in sync with code changesUpdate relevant `.rst` files when modifying public APIs or behaviorEditor Settings
Configure your Cursor editor with the following settings for this project:
```json
{
"editor.formatOnSave": true,
"editor.codeActionsOnSave": {
"source.fixAll": true
},
"editor.tabSize": 4,
"editor.insertSpaces": false,
"files.eol": "\n",
"C_Cpp.clang_format_fallbackStyle": "{ BasedOnStyle: LLVM, UseTab: Always, IndentWidth: 4, TabWidth: 4 }"
}
```
Pre-Commit Checklist
Before committing code, ensure:
1. All new public functions have English documentation comments
2. No raw `malloc`/`free` calls (use arena allocator)
3. Error handling uses the context system
4. Function names follow `myrtx_module_function` pattern
5. Header guards follow `MYRTX_MODULE_FILENAME_H` pattern
6. Corresponding unit tests are written or updated
7. Documentation files (`.rst`) are updated if API changed
8. Code is formatted with tabs (width 4)
9. All comments and docs are in English
Example Function Template
```c
/**
* @brief Allocates memory from the arena allocator
*
* Allocates a block of memory of the specified size from the provided
* arena context. Memory is not individually freed; it is released when
* the arena is reset or destroyed.
*
* @param ctx The arena context
* @param size The number of bytes to allocate
* @return Pointer to allocated memory, or NULL on failure
*/
void* myrtx_arena_alloc(myrtx_context_t* ctx, size_t size);
```
Constraints
This skill is specific to the libmyrtx project conventionsAssumes familiarity with C99 and arena-based memory managementRequires Sphinx for documentation generation (`.rst` files)Team communication is in German, but all code artifacts must be in English