Token导航 LogoToken导航TokenDH.com
研究检索可写文件unknown未标认证来源可访问许可证需确认审计通过

clean-code干净的代码

Agent Skill

clean-code 用于查找、检索和筛选相关信息,适合在 Local Agent 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

总安装

661

周安装

27

下载量

214
Local Agent

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

来源数

2

许可证

unknown

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:clean-code(干净的代码)
来源仓库:https://skills.volces.com
仓库路径:clean-code
安装命令:
OpenClaw / Moltbot / Clawbot
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 对应宿主 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.sh安装方式未标明
OpenClaw / Moltbot / Clawbot

简介

clean-code 用于查找、检索和筛选干净代码相关信息。

  • 适合在 Local Agent 中根据关键词或代码质量需求快速定位候选结果。
  • 可通过 OpenClaw / Moltbot / Clawbot 安装,具体用法请参考来源仓库。
  • 安装前建议确认权限范围、维护状态及是否触发联网或文件读写。
  • 当前分类为研究检索,实际能力需以官方文档为准。

SKILL.md

Clean Code

Be concise, direct, and solution-focused. Clean code reads like well-written prose — every name reveals intent, every function does one thing, and every abstraction earns its place.

Installation

OpenClaw / Moltbot / Clawbot

npx clawhub@latest install clean-code

Core Principles

PrincipleRulePractical Test
SRPSingle Responsibility — each function/class does ONE thing"Can I describe what this does without using 'and'?"
DRYDon't Repeat Yourself — extract duplicates, reuse"Have I written this logic before?"
KISSKeep It Simple — simplest solution that works"Is there a simpler way to achieve this?"
YAGNIYou Aren't Gonna Need It — don't build unused features"Does anyone need this right now?"
Boy ScoutLeave code cleaner than you found it"Is this file better after my change?"

Naming Rules

Names are the most important documentation. A good name eliminates the need for a comment.

ElementConventionBadGood
VariablesReveal intentn, d, tmpuserCount, elapsed, activeUsers
FunctionsVerb + nounuser(), calc()getUserById(), calculateTotal()
BooleansQuestion formactive, flagisActive, hasPermission, canEdit
ConstantsSCREAMING_SNAKEmax, timeoutMAX_RETRY_COUNT, REQUEST_TIMEOUT_MS
ClassesNoun, singularManager, DataUserRepository, OrderService
EnumsPascalCase values'pending' stringStatus.Pending
Rule: If you need a comment to explain a name, rename it.

Naming Anti-Patterns

Anti-PatternProblemFix
Cryptic abbreviations (usrMgr, cfg)Unreadable in 6 monthsSpell it out — IDE autocomplete makes long names free
Generic names (data, info, item, handler)Says nothing about purposeUse domain-specific names that reveal intent
Misleading names (getUserList returns one user)Actively deceives readersMatch name to behavior, or change the behavior
Hungarian notation (strName, nCount, IUser)Redundant with type systemLet TypeScript/IDE show types; names describe purpose

Function Rules

RuleGuidelineWhy
SmallMax 20 lines, ideally 5-10Fits in your head
One ThingDoes one thing, does it wellTestable and nameable
One LevelOne level of abstraction per functionReadable top to bottom
Few ArgsMax 3 arguments, prefer 0-2Easy to call correctly
No Side EffectsDon't mutate inputs unexpectedlyPredictable behavior

Guard Clauses

Flatten nested conditionals with early returns. Never nest deeper than 2 levels.

// BAD — 5 levels deep
function processOrder(order: Order) {
  if (order) {
    if (order.items.length > 0) {
      if (order.customer) {
        if (order.customer.isVerified) {
          return submitOrder(order);
        }
      }
    }
  }
  throw new Error('Invalid order');
}

// GOOD — guard clauses flatten the structure
function processOrder(order: Order) {
  if (!order) throw new Error('No order');
  if (!order.items.length) throw new Error('No items');
  if (!order.customer) throw new Error('No customer');
  if (!order.customer.isVerified) throw new Error('Customer not verified');

  return submitOrder(order);
}

Parameter Objects

When a function needs more than 3 arguments, use an options object.

// BAD — too many parameters, order matters
createUser('John', 'Doe', 'john@example.com', 'secret', 'admin', 'Engineering');

// GOOD — self-documenting options object
createUser({
  firstName: 'John',
  lastName: 'Doe',
  email: 'john@example.com',
  password: 'secret',
  role: 'admin',
  department: 'Engineering',
});

Code Structure Patterns

PatternWhen to ApplyBenefit
Guard ClausesEdge cases at function startFlat, readable flow
Flat > NestedAny nesting beyond 2 levelsReduced cognitive load
CompositionComplex operationsSmall, testable pieces
ColocationRelated code across filesEasier to find and change
Extract FunctionComments separating "sections"Self-documenting code

Composition Over God Functions

// BAD — god function doing everything
async function processOrder(order: Order) {
  // Validate... (15 lines)
  // Calculate totals... (15 lines)
  // Process payment... (10 lines)
  // Send notifications... (10 lines)
  // Update inventory... (10 lines)
  return { success: true };
}

// GOOD — composed of small, focused functions
async function processOrder(order: Order) {
  validateOrder(order);
  const totals = calculateOrderTotals(order);
  const payment = await processPayment(order.customer, totals);
  await sendOrderConfirmation(order, payment);
  await updateInventory(order.items);
  return { success: true, orderId: payment.orderId };
}

Return Type Consistency

Functions should return consistent types. Use discriminated unions for multiple outcomes.

// BAD — returns different types
function getUser(id: string) {
  const user = database.find(id);
  if (!user) return false;     // boolean
  if (user.isDeleted) return null; // null
  return user;                 // User
}

// GOOD — discriminated union
type GetUserResult =
  | { status: 'found'; user: User }
  | { status: 'not_found' }
  | { status: 'deleted' };

function getUser(id: string): GetUserResult {
  const user = database.find(id);
  if (!user) return { status: 'not_found' };
  if (user.isDeleted) return { status: 'deleted' };
  return { status: 'found', user };
}

Anti-Patterns

Anti-PatternProblemFix
Comment every lineNoise obscures signalDelete obvious comments; comment *why*, not *what*
Helper for one-linerUnnecessary indirectionInline the code
Factory for 2 objectsOver-engineeringDirect instantiation
utils.ts with 1 functionJunk drawer filePut code where it's used
Deep nestingUnreadable flowGuard clauses and early returns
Magic numbersUnclear intentNamed constants
God functionsUntestable, unreadableSplit by responsibility
Commented-out codeDead code confusionDelete it; git remembers
TODO sprawlNever gets doneTrack in issue tracker, not code
Premature abstractionWrong abstraction is worse than noneWait for 3+ duplicates before abstracting
Copy-paste programmingDuplicated bugsExtract shared logic
Exception-driven control flowSlow and confusingUse explicit conditionals
Stringly-typed codeTypos and missed casesUse enums or union types
Callback hellPyramid of doomUse async/await

Pre-Edit Safety Check

Before changing any file, answer these questions to avoid cascading breakage:

QuestionWhy
What imports this file?Dependents might break on interface changes
What does this file import?You might need to update the contract
What tests cover this?Tests might fail — update them alongside code
Is this a shared component?Multiple consumers means wider blast radius
File to edit: UserService.ts
├── Who imports this? → UserController.ts, AuthController.ts
├── Do they need changes too? → Check function signatures
└── What tests cover this? → UserService.test.ts
Rule: Edit the file + all dependent files in the SAME task. Never leave broken imports or missing updates.

Self-Check Before Completing

Before marking any task complete, verify:

CheckQuestion
Goal met?Did I do exactly what was asked?
Files edited?Did I modify all necessary files, including dependents?
Code works?Did I verify the change compiles and runs?
No errors?Do lint and type checks pass?
Nothing forgotten?Any edge cases or dependent files missed?

NEVER Do

  1. NEVER add comments that restate the code — if the code needs a comment to explain *what* it does, rename things until it doesn't
  2. NEVER create abstractions for fewer than 3 use cases — premature abstraction is worse than duplication
  3. NEVER leave commented-out code in the codebase — delete it; version control exists for history
  4. NEVER write functions longer than 20 lines — extract sub-functions until each does one thing
  5. NEVER nest deeper than 2 levels — use guard clauses, early returns, or extract functions
  6. NEVER use magic numbers or strings — define named constants with clear semantics
  7. NEVER edit a file without checking what depends on it — broken imports and missing updates are the most common source of bugs in multi-file changes
  8. NEVER leave a task with failing lint or type checks — fix all errors before marking complete

References

Detailed guides for specific clean code topics:

ReferenceDescription
Anti-Patterns21 common mistakes with bad/good code examples across naming, functions, structure, and comments
Code SmellsClassic code smells catalog with detection patterns — Bloaters, OO Abusers, Change Preventers, Dispensables, Couplers
Refactoring CatalogEssential refactoring patterns with before/after examples and step-by-step mechanics

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

Local Agent

72.7%
按下载量换算156

安全审计

Socket

通过

权限和风险

可写文件

该 Skill 可能写入或修改本地文件,使用前需要确认目标目录和修改范围。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。当前只有一个来源,正式发布前建议补源仓库或其他目录站核验。

来源信息

继续浏览同类 Skills