dominic/Tactility
1
0
Fork 0
mirror of https://github.com/ByteWelder/Tactility.git synced 2026-10-17 02:45:05 +00:00
Code Issues Packages Projects Releases Wiki Activity

Update coding style

Browse Source
This commit is contained in:
Ken Van Hoeylandt 2026-09-20 00:19:15 +02:00
parent 9782279ee4
commit 18ded4aa9c
1 changed files with 7 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
.claude/rules/coding-style.md
View File

@ -2,8 +2,8 @@
Two conventions coexist; which one to use depends on the project layer: Two conventions coexist; which one to use depends on the project layer:
- **C code** (TactilityKernel, drivers): `lower_snake_case` for files, functions, variables. `UpperCamelCase` for types. Files in `source/`, `include/`, `private/` directories. - **C code**: `lower_snake_case` for files, functions, variables. `UpperCamelCase` for types. Files in `source/`, `include/`, `private/` directories.
- **C++ code** (Tactility, apps, services): `UpperCamelCase` for files and types. `lowerCamelCase` for functions. Files in `Source/`, `Include/`, `Private/` directories. - **C++ code**: `UpperCamelCase` for files and types. `lowerCamelCase` for functions. Files in `Source/`, `Include/`, `Private/` directories.
For projects that emit C headers and have a C++ implementation file: the internal C++ function naming should be snake_case. For projects that emit C headers and have a C++ implementation file: the internal C++ function naming should be snake_case.
@ -11,24 +11,10 @@ Formatting is enforced by `.clang-format` (LLVM-based, 4-space indent, no column
Never throw exceptions — use return types for error handling. Use `enum class` over plain `enum` when writing C++ code. Never throw exceptions — use return types for error handling. Use `enum class` over plain `enum` when writing C++ code.
Do not add redundant null checks for parameters with an explicit non-null precondition. Do not add redundant null checks for parameters with an explicit non-null precondition.
Code Comments: Code Comments (important!):
- Should be as short as possible, leaving only important context. - Should be minimal, but must contain critical information.
- Should avoid explaining what the code does, unless the code complexity is high enough to warrant an explanation. - Must not explain how code was before, or how it was changed.
- Must avoid explaining how the code was before, or how it was changed.
- Should explain why code is implemented.
- Should be as brief as possible without losing critical information.
- Should avoid explaining what was not implemented. - Should avoid explaining what was not implemented.
- Should avoid referring to designs of other subsystems. - Must avoid referring to designs of other subsystems.
- Must avoid interjections: avoid hyphens or braces to interject. If interjections provide crucial info, use Doxygen entity/anchor references like: - Must avoid interjections: avoid hyphens or braces to interject.
/**
* A dedicated completion \signal for one app instance's task.
* Whichever \side finishes with it last is the one that deletes `semaphore` and frees this struct.
*
* \signal Not the task's shared default FreeRTOS notification, which app_event.cpp's AppEventSubscription also uses.
* An unrelated event delivered to the same task could otherwise unblock a waiter early.
* \side The exiting task or a concurrent app_scheduler_stop() that found the entry in time and is waiting on `semaphore`.
*/
```