一键导入
clean-code-functions
Use when designing, reviewing, or refactoring functions — applies Clean Code function principles for small, focused, well-argumented functions
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Use when designing, reviewing, or refactoring functions — applies Clean Code function principles for small, focused, well-argumented functions
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
Use when deciding whether, how, or where to write code comments — applies Clean Code comment principles
Use when designing or reviewing exception handling, error boundaries, or error propagation patterns — applies Clean Code error handling principles
Use when choosing names for variables, functions, classes, or modules — applies Clean Code naming principles for clear, intention-revealing identifiers
Routes to Clean Code sub-skills for naming, functions, comments, and error handling based on Robert C. Martin's Clean Code
Detects code smells and recommends specific refactorings. Covers the 22 canonical code smells from Fowler's Refactoring with Python examples.
Techniques for breaking down and reorganizing methods: Extract Method, Inline Method, Replace Temp with Query, Introduce Explaining Variable, Split Temporary Variable, Replace Method with Method Object, Substitute Algorithm. All with Python before/after examples.
基于 SOC 职业分类
| name | clean-code-functions |
| description | Use when designing, reviewing, or refactoring functions — applies Clean Code function principles for small, focused, well-argumented functions |
Based on Robert C. Martin's Clean Code, Chapter 3: Functions.
Trigger on:
The first rule of functions is they should be small. The second rule is they should be smaller than that. Functions should rarely be longer than 20 lines.
A function should do one thing, do it well, and do it only. If you can extract another function with a meaningful name, the original is doing more than one thing.
# Bad — does two things
def process_user(user):
# validates
if not user.email:
raise ValueError("Email required")
# saves
db.save(user)
# Good — one thing each
def validate_user(user):
if not user.email:
raise ValueError("Email required")
def save_user(user):
db.save(user)
All statements in a function should be at the same level of abstraction. Don't mix high-level business logic with low-level implementation details.
We want every function to be followed by those at the next level of abstraction, reading top-down like a newspaper article.
A long descriptive name is better than a short enigmatic name. If you have a well-named function, comments are often redundant.
The ideal number of arguments is zero (niladic). One is fine (monadic). Two is ok (dyadic). Three should be avoided (triadic). More than three requires special justification.
# Bad
def make_circle(x, y, radius, color, stroke_width, fill): ...
# Good
def make_circle(center: Point, radius: float, style: CircleStyle): ...
Boolean arguments loudly declare the function does more than one thing.
# Bad
def render_page(is_uppercase):
if is_uppercase:
...render uppercase...
# Good
def render_uppercase_page():
...
def render_lowercase_page():
...
A function should do what its name says. Hidden side effects create temporal couplings and order dependencies.
A function should either do something or answer something, but not both. Either change state or return data.
Try/catch bodies are ugly. Extract the body into a function of its own.
Distilled from Clean Code by Robert C. Martin, Chapter 3: Functions.