R013: 注释的废弃代码

Detect commented-out code blocks in OpenHarmony test files and report them.

31|6|Updated Jan 29, 2026
One-click install
npx skills add https://github.com/openharmonyinsight/openharmony-skills --skill r013
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: R013: 注释的废弃代码
Source: https://github.com/openharmonyinsight/openharmony-skills/tree/main/skills/check-test-code-quality/rules/R013
Command: npx skills add https://github.com/openharmonyinsight/openharmony-skills --skill r013

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill finds test files that keep large blocks of commented-out, no-longer-used code, which reduces readability and makes reviews harder.

Core Features & Use Cases

  • Targets test files automatically: Scans only .test.ets, .test.ts, and .test.js files.
  • Detects abandoned code comment blocks: Flags consecutive comment blocks (3+ lines) that appear to contain code rather than pure documentation.
  • Attributes findings to the right test case: Traces the commented block’s location to the nearest surrounding it() block, or marks it as - if outside.
  • Excludes documentation-style JSDoc: Skips blocks that look like JSDoc (e.g., includes multiple @tc.*, @param, @return-style markers).

Quick Start

Use R013 to scan your test directory and automatically get a list of commented-out dead code blocks with their file, line range, and owning it() testcase.

Frequently Asked Questions about R013: 注释的废弃代码

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I detect and clean up commented-out dead code in test files?

To detect commented-out dead code in test files, scan `.test.ets`, `.test.ts`, and `.test.js` sources to flag consecutive 3+ line comment blocks containing code-like patterns, mapping each finding to its enclosing `it()` testcase for structured cleanup reporting.

How do I find commented-out abandoned code blocks without flagging JSDoc comments?

Finding commented-out abandoned code blocks while excluding JSDoc requires filtering consecutive comment lines and skipping blocks with documentation markers like `@tc.*`, `@param`, or `@return`, ensuring only code-like patterns are reported for removal.

How can I map commented-out code issues to specific test cases during static analysis?

Mapping commented-out code issues to test cases involves tracing each detected comment block's location to the nearest surrounding `it()` block, or marking it as `-` if outside, providing precise attribution for code reviews.

Does this static analysis tool work with OpenHarmony .test.ets files?

Yes, this static analysis tool works with OpenHarmony `.test.ets` files, alongside `.test.ts` and `.test.js` formats, automatically scanning them to identify outdated commented implementations left for reference.

What is the minimum consecutive comment line threshold for detecting dead code blocks?

The minimum threshold for detecting dead code blocks is 3 consecutive comment lines, which helps distinguish substantial abandoned code fragments from brief inline explanations or single-line notes.

What is included in the structured issue report for commented-out dead code?

The structured issue report for commented-out dead code includes the file path, line range, owning `it()` testcase block, and code snippets, providing developers with actionable details for direct cleanup.