Skip to main content

c-code-style

Write, edit, or review C (and C-compatible header) code according to C coding style rules, then check and run clang-format to enforce formatting. Trigger on "write C code", "edit a .c/.h file", "review C code style", "format C code", "run clang-format", "check clang-format", "apply the C style guide".

소스 정보

저장소
MaJerle/c-code-style
최근 소스 활동
2026년 8월 4일 21:37
감지된 SKILL.md 언어
영어
스타
1,352
포크
269

설치 방법

기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.

소스 파일 검토

설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.

SKILL.md 표시 중

SKILL.md
소스 지침 · 읽기 전용 미리보기
name
c-code-style
description
Write, edit, or review C (and C-compatible header) code according to C coding style rules, then check and run clang-format to enforce formatting. Trigger on "write C code", "edit a .c/.h file", "review C code style", "format C code", "run clang-format", "check clang-format", "apply the C style guide".
# C code style This skill applies whenever you are writing, editing, or reviewing `.c` or `.h` files in a project that adopts this style guide. The full rule set lives in [`CODING_RULES.md`](../../../CODING_RULES.md) at the repository root — that file is the single source of truth (this repository's `README.md` is just a symlink to it, so it renders on the GitHub front page). This skill exists to make the rules operational: what to self-apply while writing code, and how to run the formatter afterward. ## 1. Read the rules first Before writing or editing C code, read `CODING_RULES.md` in this repository (or wherever this skill was installed alongside it — if it's not there, the checklist in step 3 below is a self-contained fallback). Do not rely on memory of "typical" C style — several of this guide's rules are deliberately non-default (e.g. `(void)` on zero-parameter functions, at most 2 `return` points per function, no `stdbool.h`). ## 2. What `clang-format` fixes for you Don't hand-format these — write reasonably and let the formatter normalize them in step 4: indentation and spacing, brace placement, pointer-asterisk alignment, function-prototype alignment, trailing commas in struct initializers, blank-line and parenthesis spacing. ## 3. What `clang-format` will NOT fix — apply these yourself while writing These are semantic or naming rules; a formatter cannot infer them. Apply them as you write, not after: - Names (variables, parameters, struct/enum members) are lowercase with underscores and **at least 3 characters**. Never a bare `__`/`_` prefix. `static` module-private functions use a `prv_` prefix. - Use `stdint.h` types (`uint8_t`, `int32_t`, ...) except `char`/`float`/`double`. Avoid `stdbool.h`; use `1`/`0`. - Don't rely on static initializers for `global`/`static` variables that need a real startup value in embedded contexts — give the module an `init()` function instead. - Declare all locals at the top of a block, grouped by type, in order: custom structs/enums (and their pointers) → integers (widest unsigned first) → floating point. - `const`-correct pointers and parameters; generic pointers are `void*`, cast internally, never cast a `void*` return value. - Every function with zero parameters uses `(void)`, never empty `()`. - A function has **at most 2 `return` points**: one early return for parameter/argument validation, one at the end. No `return` in the middle — use a return-value variable to accumulate the result instead. - Check a pointer against `NULL` before dereferencing it (unless the surrounding code guarantees it can't be `NULL`). After `free(ptr)`, immediately set `ptr = NULL`. - Boolean-treated variables are compared with `if (x)` / `if (!x)`, never `== 1` / `== 0`; counter/value variables use `> 0` / `== 0`, never bare `if (x)`. - Doxygen: every function (including `static` ones) gets a `\brief`, a `\param[in]`/`\param[out]` per parameter, and a `\return` if it returns non-`void`. The doc block goes at the function's **definition** (where the body is, typically the `.c` file) — never duplicated at the declaration in the header. Pad tags so description text starts at column 22 (see `template.c`/`template.h` for the exact alignment). Wrap identifiers, constants, and literals referenced in prose in backticks. ## 4. Format the code After writing or editing any `.c`/`.h` file, run the formatter using this repository's `.clang-format` (it's found automatically by walking up from the file's directory — no path needed): ```sh scripts/check-format.sh <changed-file.c> [<changed-file.h> ...] ``` This script: 1. Checks `clang-format` is on `PATH` and is version `20` or newer (this repo's minimum — see `CODING_RULES.md`, General rules). 2. If missing or too old, prints the install command for the current OS (`brew install llvm` on macOS, distro package or LLVM apt repo on Linux, the LLVM installer on Windows) and exits non-zero — install it, then re-run. 3. Otherwise runs `clang-format -i` on the given files. To verify compliance without writing changes (e.g. before reporting a task done), use `--check` instead: ```sh scripts/check-format.sh --check <file.c> [<file.h> ...] ``` Exits `0` if already compliant, non-zero (with the specific violations) if not. ## 5. Verified behavior This flow was tested directly in this repository: `check-format.sh` correctly refuses to run when `clang-format` is absent (prints the right install command per OS and exits 1), and — once `clang-format` is installed — correctly detects a deliberately mis-formatted file with `--check`, fixes it with the default (in-place) mode, and re-verifies clean afterward. `template.c` and `template.h` in this repository both pass `--check` as-is — use them as a reference for exact formatting and doxygen alignment.
GitHub에서 보기