libmyrtx C99 Development Standards
This skill enforces comprehensive coding standards and best practices for libmyrtx, a real-time operating system library written in C99.
What This Skill Does
Ensures consistent code quality across the libmyrtx codebase by enforcing:
C99 language standards complianceProper header guard conventionsRequired documentation for all public APIsMemory management best practices using arena allocatorsContext-based error handling patternsConsistent naming conventions across all modulesTest coverage requirementsEnglish-only documentation and commentsProper code formatting with tabsInstructions for AI Agent
When working with libmyrtx code, follow these standards rigorously:
1. C99 Standards Compliance
For all `.c` and `.h` files:
Write strictly C99-compliant codeDo not use C11/C17/C23 featuresAvoid compiler-specific extensions unless absolutely necessary and clearly documentedTest code compiles with `-std=c99 -pedantic` flags2. Header Guards
For all `.h` files:
Use the pattern: `MYRTX_MODULE_FILENAME_H`Example: For `src/memory/arena.h`, use `MYRTX_MEMORY_ARENA_H`Format: ```c
#ifndef MYRTX_MODULE_FILENAME_H
#define MYRTX_MODULE_FILENAME_H
/* header content */
#endif /* MYRTX_MODULE_FILENAME_H */
```
3. Documentation Requirements
For all public functions in `.c` and `.h` files:
Add documentation comments above function declarationsUse this format: ```c
/**
* Brief description of what the function does.
*
* @param param_name Description of parameter
* @return Description of return value
*/
```
Write all documentation in **English only** (team communication may be German, but code/docs must be English)Keep `.rst` documentation files synchronized with code changes4. Memory Management
For `.c` files:
**Prefer arena allocators** over raw `malloc`/`free`Use the project's arena allocation APIs: `myrtx_arena_alloc()`, etc.Avoid manual memory management unless required for specific low-level operationsDocument any raw `malloc`/`free` usage with justificationAlways check allocation results for NULLExample pattern:
```c
void* ptr = myrtx_arena_alloc(arena, size);
if (ptr == NULL) {
myrtx_context_set_error(ctx, MYRTX_ERR_NO_MEMORY);
return NULL;
}
```
5. Error Handling
For `.c` files:
Use the **context system** for error propagationCall `myrtx_context_set_error(ctx, error_code)` to report errorsCheck context for errors after calling functions that may failDo not use `errno` or global error variablesReturn appropriate error indicators (NULL, -1, error codes) alongside context errorsExample:
```c
int myrtx_module_function(myrtx_context_t* ctx, int param) {
if (param < 0) {
myrtx_context_set_error(ctx, MYRTX_ERR_INVALID_PARAM);
return -1;
}
/* ... */
return 0;
}
```
6. Naming Conventions
For all `.c` and `.h` files:
**Public functions**: `myrtx_module_function` pattern - Example: `myrtx_arena_create`, `myrtx_task_schedule`
**Static/private functions**: `module_function` or `_myrtx_module_function`**Types**: `myrtx_module_type_t` (with `_t` suffix) - Example: `myrtx_context_t`, `myrtx_arena_t`
**Macros/constants**: `MYRTX_MODULE_CONSTANT` - Example: `MYRTX_MAX_TASKS`, `MYRTX_ERR_NO_MEMORY`
7. Test Coverage
For source files in `src/`:
Each `.c` file should have a corresponding test filePlace tests in appropriate test directory (e.g., `tests/test_arena.c` for `src/memory/arena.c`)Ensure new functions have test cases covering: - Normal operation
- Edge cases
- Error conditions
- Boundary values
8. Code Formatting
For all `.c` and `.h` files:
**Use tabs for indentation** (NOT spaces)Tab width: 4 spaces visual equivalentPlace opening braces on same line for functions and control structuresAdd whitespace around operators for readabilityFormat on save should be enabled in editorExample:
```c
int myrtx_example_function(int param) {
if (param > 0) {
return param * 2;
} else {
return 0;
}
}
```
9. Language Requirements
For `.c`, `.h`, `.md`, and `.rst` files:
Write **all comments in English**Write **all documentation in English**Write **all commit messages in English**Use clear, professional technical EnglishNote: Internal team communication may be in German, but all code artifacts must be English10. Editor Settings
Configure your editor with:
Format on save: EnabledAuto-fix on save: whitespace, semicolonsLint on save: EnabledTab size: 4Insert type: Tab (not spaces)Constraints
Never use features beyond C99 standardNever use spaces for indentation (tabs only)Never omit documentation for public functionsNever use `malloc`/`free` when arena allocators are availableNever bypass the context error systemNever write documentation or comments in languages other than EnglishNever leave `.rst` documentation out of sync with code changesExamples
Good: Properly documented function with arena allocation
```c
/**
* Creates a new task in the scheduler.
*
* @param ctx Context for error reporting
* @param arena Arena allocator for memory
* @param priority Task priority (0-255)
* @return Pointer to new task, or NULL on error
*/
myrtx_task_t* myrtx_task_create(myrtx_context_t* ctx, myrtx_arena_t* arena, uint8_t priority) {
myrtx_task_t* task = myrtx_arena_alloc(arena, sizeof(myrtx_task_t));
if (task == NULL) {
myrtx_context_set_error(ctx, MYRTX_ERR_NO_MEMORY);
return NULL;
}
task->priority = priority;
return task;
}
```
Bad: Missing docs, raw malloc, no error handling
```c
myrtx_task_t* create_task(uint8_t priority) {
myrtx_task_t* task = malloc(sizeof(myrtx_task_t)); // Should use arena
task->priority = priority; // No NULL check
return task;
}
```