Skip to main content

code-comments

Comment style for the Charty codebase — use when writing or editing any Kotlin in charty/ or composeApp/, and before committing. This codebase is self-documenting: essentially no inline `//` comments. Do NOT add comments that restate what the code, a name, or a test already says (e.g. `LineChartConfig() // must not throw`, `if (x == 0) return // guard`). Keep KDoc; drop inline noise.

소스 정보

저장소
hi-manshu/charty
최근 소스 활동
2026년 8월 11일 13:00
감지된 SKILL.md 언어
영어
스타
1,291
포크
60

설치 방법

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

소스 파일 검토

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

SKILL.md 표시 중

SKILL.md
소스 지침 · 읽기 전용 미리보기
name
code-comments
description
Comment style for the Charty codebase — use when writing or editing any Kotlin in charty/ or composeApp/, and before committing. This codebase is self-documenting: essentially no inline `//` comments. Do NOT add comments that restate what the code, a name, or a test already says (e.g. `LineChartConfig() // must not throw`, `if (x == 0) return // guard`). Keep KDoc; drop inline noise.
# Code comments Charty is written to read without inline commentary: clear names, small functions, and KDoc on public declarations. Match that. The bar for adding an inline `//` comment is very high. ## Rule **Do not add inline `//` comments.** Before writing one, assume it should not exist. The codebase has almost none, and they read as noise against that style. **Never** write a comment that restates what the code, a symbol name, or a test name already conveys. These are all banned: ```kotlin LineChartConfig() // must not throw ← the test name already says this if (range == 0f) return // guard against zero range ← the code already says this val brush = Brush.linearGradient(color.value) // create brush ← restates the call values.filter { it > 0f } // keep positives ← restates the call // regression: ... ← put context in the test name instead ``` Instead, encode the intent where it belongs: - **What / behaviour** → a good function or variable name, or a descriptive `@Test` name (`fromMinValue_negativeBar_growsUpward`). - **Non-obvious rationale (a real "why")** → the function's **KDoc**, not an inline comment. If a guard or fallback exists for a subtle reason (overflow, a Compose phase, a platform quirk), state it in the KDoc of the function that contains it. ## Applying it - When you catch yourself about to write `//`, first try to rename something or add/extend KDoc. - When editing existing code, remove inline `//` comments that only restate the code — but keep: - KDoc (`/** … */`) and its `@param`/`@property`/`@return` tags, - license/copyright headers, - comments **inside** KDoc ```kotlin examples (they document the example), - `// TODO`/`// FIXME` that track real outstanding work. - This is a **commit gate**: a diff that adds inline `//` comments restating the code is not ready. `commit-with-stats` checks for it. Quick self-check on a staged diff: ```bash git diff --cached -U0 -- '*.kt' | grep -E '^\+' | grep -E '//' | grep -vE '/\*\*|^\+\s*\*|https?://|TODO|FIXME' ``` Every line it prints should be justified as a real "why" that could not live in a name or KDoc — otherwise delete the comment.
GitHub에서 보기