skills/check-test-code-quality/rules/R019/SKILL.md
# R019: .key重复 > R019是工程级属性重复检测的基类规则。R020(.id重复)与此规则共享完全相同的扫描逻辑,仅检测目标不同。共享函数定义见 [references/project_level_scan.md](../../references/project_level_scan.md)。 ## 规则信息 | 属性 | 值 | |------|-----| | 规则编号 | R019 | | 问题类型 | .key重复 | | 严重级别 | Critical | | 规则复杂度 | complex | | 扫描范围 | 同一独立XTS工程内的所有源代码文件(`.ets`, `.ts`, `.js`) | | testcase字段 | `-`(.key()不在it()块内) | ## 问题描述 一个独立XTS工程下的页面设计中,`.key()` 的字符串参数值不允许重复。即同一个独立XTS工程中,所有源代码文件里 `.key('xxx')` 的字符串参数值不能重复。 ## 检测模式 ```python import re KEY_PATTERN = re
npx skillsauth add openharmonyinsight/openharmony-skills skills/check-test-code-quality/rules/R019Install this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
R019是工程级属性重复检测的基类规则。R020(.id重复)与此规则共享完全相同的扫描逻辑,仅检测目标不同。共享函数定义见 references/project_level_scan.md。
| 属性 | 值 |
|------|-----|
| 规则编号 | R019 |
| 问题类型 | .key重复 |
| 严重级别 | Critical |
| 规则复杂度 | complex |
| 扫描范围 | 同一独立XTS工程内的所有源代码文件(.ets, .ts, .js) |
| testcase字段 | -(.key()不在it()块内) |
一个独立XTS工程下的页面设计中,.key() 的字符串参数值不允许重复。即同一个独立XTS工程中,所有源代码文件里 .key('xxx') 的字符串参数值不能重复。
import re
KEY_PATTERN = re.compile(
r'\.key\s*\(\s*(["\'])([^"\']+)\1\s*\)',
re.MULTILINE
)
复用 references/project_level_scan.md 中的 find_independent_projects() 函数。必须使用修正后的版本,正确处理group类型父BUILD.gn(见陷阱6)。
关键: 需要递归收集工程目录下的所有源代码文件(包括子目录),与R011不同(R011只收集根目录下的测试文件)。因为.key()可能出现在工程的任意子目录的.ets文件中。
复用 get_project_source_files(project_dir)。
在工程内的源代码文件中,提取所有 .key('xxx') 或 .key("xxx") 的字符串参数。
复用 collect_attr_values(project_dir, source_files, base_dir, KEY_PATTERN)。
复用 find_duplicate_groups(items)。
关键: 只为每个重复组的第一次出现创建一条问题报告。
def scan_r019(scan_root, base_dir):
issues = []
projects = find_independent_projects(scan_root)
for project_dir in projects:
source_files = get_project_source_files(project_dir)
if not source_files:
continue
keys = collect_attr_values(project_dir, source_files, base_dir, KEY_PATTERN)
duplicates = find_duplicate_groups(keys)
for dup in duplicates:
rel_project = os.path.relpath(project_dir, base_dir)
other_info = '; '.join(dup['other_locations'])
issues.append({
'rule': 'R019',
'type': '.key重复',
'severity': 'Critical',
'file': dup['first_file'],
'line': dup['first_line'],
'testcase': '-',
'snippet': f".key('{dup['value']}')",
'suggestion': (
f"路径: {dup['first_file']}, 行号: {dup['first_line']}, "
f"问题描述: 在独立XTS工程 '{rel_project}' 中,.key值 "
f"'{dup['value']}' 重复 {dup['count']} 次。"
f"重复位置: {other_info}。"
),
})
return issues
确保.key()的值在工程内唯一。修改重复的key值为有意义的唯一标识。
路径: {文件路径}, 行号: {行号}, 问题描述: 在独立XTS工程 '{工程名称}' 中,.key值 '{key值}' 重复 {重复次数} 次。重复位置: {位置1}, {位置2}, ...
// File1: TestAddCustomProperty.ets(同一独立工程内)
Button('Add')
.key('buttonCustomProperty') // 第一次出现
Text('Custom')
.key('customPropertyValue') // 第一次出现
// File2: TestRemoveCustomProperty.ets(同一独立工程内)
Button('Remove')
.key('buttonCustomProperty') // ✗ 错误:与File1重复
Text('RemoveCustom')
.key('customPropertyValue') // ✗ 错误:与File1重复
// File1: TestAddCustomProperty.ets(同一独立工程内)
Button('Add')
.key('addButtonCustomProperty') // ✓ key值唯一
Text('Custom')
.key('addCustomPropertyValue') // ✓ key值唯一
// File2: TestRemoveCustomProperty.ets(同一独立工程内)
Button('Remove')
.key('removeButtonCustomProperty') // ✓ key值唯一
Text('RemoveCustom')
.key('removeCustomPropertyValue') // ✓ key值唯一
R011只收集工程根目录下的测试文件(os.listdir(project_dir)),而R019需要递归收集工程下所有子目录的源代码文件(os.walk(project_dir)),因为.key()可能出现在entry/src/ohosTest/ets/MainAbility/pages/等深层子目录的.ets文件中。
如果.key()的参数不是字符串字面量而是变量(如.key(myKeyVar)),则不进行重复检查。正则.key\s*\(\s*(["\'])([^"\']+)\1\s*\)已经自然排除了这种情况。
与R011/testsuite重复规则一致,不同独立XTS工程之间的同名.key值不视为重复。
同一组重复的.key值只报告第一次出现的行号,后续重复行号在修复建议中列出。避免同一组重复被多次报告。
.key('') 或 .key("") 空字符串key值不进行重复检查。collect_attr_values已通过 if not attr_value: continue 过滤。
严重性: 极严重,导致arkui子系统多层嵌套工程全部漏检(49→997个工程,80→1567个问题)
详见 references/TRAPS.md 陷阱10,以及 references/project_level_scan.md 中的
find_independent_projects()实现。
| 字段 | 值 |
|------|-----|
| rule | R019 |
| type | .key重复 |
| severity | Critical |
| file | 相对路径 |
| line | .key()所在行号 |
| testcase | - |
| snippet | .key('customPropertyValue') |
| suggestion | 路径: {文件路径}, 行号: {行号}, 问题描述: 在独立XTS工程 '{工程名}' 中,.key值 '{key值}' 重复 {次数} 次。重复位置: {文件:行号}; ... |
工程: arkui/ace_c_arkui_test_api13
重复值:customPropertyValue
1、arkui/ace_c_arkui_test_api13/entry/src/ohosTest/ets/MainAbility/pages/customproperty/TestRemoveCustomProperty.ets 45行 .key('customPropertyValue')
2、arkui/ace_c_arkui_test_api13/entry/src/ohosTest/ets/MainAbility/pages/customproperty/TestAddCustomProperty.ets 37行 .key('customPropertyValue')
重复值:buttonCustomProperty
1、arkui/ace_c_arkui_test_api13/entry/src/ohosTest/ets/MainAbility/pages/customproperty/TestRemoveCustomProperty.ets 33行 .key('buttonCustomProperty')
2、arkui/ace_c_arkui_test_api13/entry/src/ohosTest/ets/MainAbility/pages/customproperty/TestAddCustomProperty.ets 38行 .key('buttonCustomProperty')
development
Run local code quality checks covering a subset of OpenHarmony gate CI (copyright, CodeArts C/C++) plus additional local checks (pylint/flake8, shellcheck/bashate, gn format). Use before committing to reduce gate failures. Triggers on: /oh-precommit-codecheck, "门禁检查", "门禁预检", "检查代码", "run codecheck", "check code quality", "lint my code", "代码检查", or after completing code implementation. WHEN to use: before git commit, before creating PR, after modifying C/C++/Python/Shell/GN files, when gate CI fails with codecheck defects, or when you want to preview what gate will flag.
development
OpenHarmony PR full lifecycle workflow. Five modes: - Commit: standardized commit with DCO sign-off and Issue linking - Create PR: commit + push to fork + create Issue + create PR on upstream - Fix Codecheck: fetch gate CI codecheck defects from a PR and auto-fix them - Review PR: fetch a PR's changes to local for code review - Fix Review: fetch unresolved review comments from a PR and auto-fix them Triggers on: /oh-pr-workflow, "提交代码", "创建PR", "提个PR", "commit", "修复告警", "修复门禁", "修复codecheck", "fix codecheck", "review pr", "review这个pr", "看下这个pr", "检视pr", "修复review", "修复检视意见", "fix review", or a GitCode PR URL with fix/review intent.
testing
分析 HM Desktop PRD 文档,提取需求信息、验证完整性、检查章节顺序(需求来源→需求背景→需求价值分析→竞品分析→需求描述)、检查 KEP 定义、检测需求冲突并生成结构化分析报告。适用于用户请求:(1) 分析或审查 PRD 文档, (2) 从需求中提取 KEP 列表, (3) 检查 PRD 完整性或一致性, (4) 将需求映射到模块架构, (5) 验证 PRD 格式合规性, (6) 验证竞品分析章节完整性。关键词:PRD分析, requirement extraction, KEP验证, completeness check, chapter order validation, 竞品分析检查, analyze PRD, 需求提取, 完整性检查, 章节顺序验证
development
基于 PRD 文档自动生成鸿蒙系统设计文档,包括架构设计文档和功能设计文档。生成前会分析 OpenHarmony 存量代码结构,确保与现有架构兼容。架构设计文档第2章必须为竞品方案分析,位于需求背景之后。适用于用户请求:(1) 生成架构设计文档, (2) 生成功能设计文档, (3) 从 PRD 生成设计文档, (4) 创建系统架构设计, (5) 编写功能规格说明, (6) 分析 OH 代码结构。关键词:architecture design, functional design, design doc, 竞品方案分析, OpenHarmony code analysis, 架构设计, 功能设计, 设计文档生成, OH代码分析, analyze codebase, competitor analysis