开发工具IDE调试器代码质量【免费下载链接】cangjie_deveco_plugins项目地址https://gitcode.com/Cangjie/cangjie_deveco_plugins点击查看免费下载本指南围绕仓颉Cangjie语言官方编码规范中的G.NAM.02「源文件名采用全小写加下划线风格」规则展开结合 cangjie_deveco_plugins 仓库中 cjlint 静态检查插件的源码实现讲清楚这条「建议」级规则的来龙去脉为什么仓颉源文件不允许使用驼峰命名、如何依据顶层元素选择文件名、以及该规则如何在 IDE 静态检查流程中落地生效。读完本文你将能够正确命名仓颉.cj源文件并理解 cjlint 规则文档、规则 ID、检查级别与屏蔽注释之间的完整关联。规则速览项内容规则 IDG.NAM.02级别建议suggestions对应 cjlint 缺陷严重级别 severity1适用范围.cj源文件名核心要求源文件名使用全小写加下划线风格禁止使用驼峰命名规则文档tools-extension/cjlint/src/main/resources/docs/G_NAM_02.md该规则属于仓颉代码质量体系中的命名Naming类规则。仓库中完整规则文档集位于 tools-extension/cjlint/src/main/resources/docs/覆盖命名G_NAM、类G_CLS、常量G_CON、声明G_DCL、格式G_FMT、函数G_FUN等十余个类别共 80 条规则G.NAM.02 即其中一条面向文件名的规则。为什么文件名必须全小写加下划线跨平台大小写语义差异规则描述部分给出了这条命名约束的根本原因文件名不采用驼峰的原因是不同系统对文件名大小写处理不同如 Windows 系统不区分大小写但是 Unix/Linux、Mac 系统则默认区分。换句话说MyClass.cj在 Windows 上可能与myclass.cj指向同一个文件但在 Unix/Linux、macOS 上却被视为两个完全不同的文件。一旦项目在多平台间共享源码依赖大小写区分文件名的代码例如 import 路径、构建脚本中的文件引用就可能出现「本地能编译、CI 上找不到文件」的隐性故障。采用全小写 下划线的命名策略从源头规避了大小写语义差异带来的不确定性保证源码在任意文件系统上都能以一致的方式被解析。文件命名选择原则与顶层元素保持一致除了命名风格约束G.NAM.02 还给出了文件命名的内容依据如果文件只包含一个包外部可见的顶层元素那么直接选择该顶层元素的名称来命名文件否则包含多个顶层元素选择能代表主要内容的元素名称作为文件名。这里「顶层元素」包括包外部可见的类、函数、类型别名等。例如一个文件里只有一个public class MyClass文件名就应该是my_class.cj元素名MyClass转为全小写下划线形式而不是MyClass.cj。正例与反例规则文档给出了完整的示例代码此处完整保留正例文件名my_class.cj对应类名MyClass符合全小写加下划线风格// my_class.cj public class MyClass { // CODE }反例文件名MyClass.cj使用了驼峰命名不符合规范// MyClass.cj 文件名不符合使用了驼峰命名 public class MyClass { // CODE }正反例的差异点非常直观类名MyClass本身采用大驼峰这是 G.NAM.03 的要求见下文但文件名必须将其转换为全小写下划线形式my_class。与相邻命名规则的配合文件内命名 vs 文件名G.NAM.02 约束的是「文件名」而文件内部的标识符命名由其他规则约束二者需要配合使用。仓库规则文档集中与之相邻的几条命名规则均在 tools-extension/cjlint/src/main/resources/docs/ 下包括规则内容要点文档G.NAM.01包名全小写多单词用下划线分隔允许数字建议以 Internet 域名反转规则开头G_NAM_01.mdG.NAM.03接口、类、struct、enum 类型及构造器、类型别名采用大驼峰测试类推荐以被测试类名开头、以 Test 结尾G_NAM_03.mdG.NAM.04函数名称采用小驼峰如sendMessage、stopServer布尔属性建议加is/has前缀G_NAM_04.mdG.NAM.05const 变量采用下划线分隔的全大写单词命名G_NAM_05.mdG.NAM.06变量、属性、函数参数、pattern 采用小驼峰泛型类型参数允许单个大写字母或大写字母加数字G_NAM_06.md可以看到命名体系的分工是文件名用全小写下划线类型名用大驼峰函数/变量用小驼峰const 用全大写。文件my_class.cj中定义public class MyClass正是「文件名与内容元素一一对应」的典型写法。规则在 cjlint 静态检查中的落地实现G.NAM.02 不仅仅是一条书写规范它在 cangjie_deveco_plugins 仓库的cjlint 静态检查插件中拥有完整的工具链支撑。cjlint 是 tools-extension 下三个代码质量子插件之一cjformat 格式化、cjcov 覆盖率、cjlint 静态检查负责将上述规则文档作为检查依据落地到 IDE 中。规则 ID 与文档的自动映射cjlint 引擎在展示检查结果时会把缺陷的规则 ID 自动映射到对应的规则文档路径供开发者点击查看详细规范。这一逻辑实现在 CjlintCodeCheckCmd.java 的getRuleDocPath方法中String result description.substring(ZERO, description.indexOf(COLON)).replace(POINT, UNDER_LINE); docPath.append(DOCS).append(File.separator).append(result).append(MD_TYPE);即把描述中的规则 IDG.NAM.02中的.替换为_得到G_NAM_02再拼接.md后缀最终定位到 G_NAM_02.md。这正是仓库中规则文档按G_XXX_NN.md命名存放的原因——文档文件名与规则 ID 一一对应。级别映射建议级缺陷的严重程度G.NAM.02 的级别是「建议」。在 cjlint 的结果解析中CjlintCodeCheckCmd.java引擎从引擎输出 JSON 中读取defectLevel字段将suggestions级别映射为 severity1、mandatory级别映射为 severity2对应 IDE 问题面板中不同等级的告警展示。规则引擎的底层输出结构由 DefectInfo.java 定义包含defectLevel、file、description、defectType、line、column等字段。引擎注册与规则配置cjlint 通过 META-INF/cjlint.xml 将com.huawei.deveco.cjlint.CjlintEngine注册为com.huawei.codelinter扩展点的 engineProvider从而接入 IDE 的代码检查框架规则是否参与检查可由工程根目录下的cjlint_rule_list.json自定义其 JSON 映射类为 CjlintRuleListConfig.java字段ruleList配置文件键名为RuleList检查范围可由工程根目录下的code-linter.json5中的files与ignore字段控制映射类为 CodeLinterJson5Config.java其中ignore使用相对工程根目录的 glob 路径。相关筛选逻辑见 CjlintCodeCheckCmd.java规则 ID 的解析正则由 CodeCheckConstantUtil.java 定义^([A-Z_]{1,10}_\d{1,5})引擎名称固定为cjlint。屏蔽机制行级与整文件当某处确需例外时可以通过注释屏蔽缺陷。规则 IDG.NAM.02经 CjLintManager.java 的getIgnoreRule转换匹配规则 ID 前缀、将_还原为.并加!前缀得到!G.NAM.02配合 PsiHandler.java 中定义的注释格式使用单行/单点屏蔽在对应行添加注释// cjlint-ignore !G.NAM.02整文件屏蔽文件首行加// cjlint-ignore -start !G.NAM.02 ...文件末尾加// cjlint-ignore -end相关常量与逻辑见 PsiHandler.java 与 CjlintEngine.java 的shieldSelectedDefect/shieldDefect实现。实践建议总结命名规则仓颉.cj源文件一律使用全小写加下划线命名如my_class.cj、http_client.cj不使用驼峰内容对应文件仅含一个包外可见顶层元素时文件名取该元素名的全小写下划线形式含多个元素时取能代表主要内容的元素名跨平台一致性全小写下划线命名规避了 Windows 与 Unix/Linux、macOS 之间文件系统大小写语义差异导致的构建隐患工具联动规则文档G_NAM_02.md与规则 IDG.NAM.02一一对应可在 cjlint 检查结果中直接跳转查看如需调整检查范围可通过cjlint_rule_list.json、code-linter.json5与cjlint-ignore注释按需配置。赞分享开发工具IDE调试器代码质量【免费下载链接】cangjie_deveco_plugins项目地址https://gitcode.com/Cangjie/cangjie_deveco_plugins点击查看免费下载相关推荐仓颉包命名规范 G.NAM.01 全解析全小写下划线包名约定与 cjlint 静态检查落地仓颉包命名规范 G.NAM.01 全解析全小写下划线包名约定与 cjlint 静态检查落地 本文以仓颉Cangjie静态检查工具 cjlint 的规则文档开发工具IDE调试器代码质量仓颉函数命名规范 G.NAM.04小驼峰命名规则与 cjlint 静态检查实践仓颉函数命名规范 G.NAM.04小驼峰命名规则与 cjlint 静态检查实践 导读 本文围绕仓颉Cangjie编程规范条目 G.NAM.04「函数名称应开发工具IDE调试器代码质量CActor 代码风格指南仓颉语言 Actor 框架的命名、格式化与工程规范全解析CActor 代码风格指南仓颉语言 Actor 框架的命名、格式化与工程规范全解析 本文以 CActor 项目官方代码风格指南为核心系统讲解这套基于仓颉C后端并发编程分布式上一篇从论文到临床Multi-Agent Medical Assistant的PubMed与网络搜索集成方案下一篇3步实现Plyr播放器自适应布局从固定尺寸到全场景适配创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/10/14 2:08:29 · 阅读 1.2k 仓颉语言命名规范 G.NAM.02 实战：源文件名采用全小写加下划线风格
开发工具IDE调试器代码质量【免费下载链接】cangjie_deveco_plugins项目地址https://gitcode.com/Cangjie/cangjie_deveco_plugins点击查看免费下载本指南围绕仓颉Cangjie语言官方编码规范中的G.NAM.02「源文件名采用全小写加下划线风格」规则展开结合 cangjie_deveco_plugins 仓库中 cjlint 静态检查插件的源码实现讲清楚这条「建议」级规则的来龙去脉为什么仓颉源文件不允许使用驼峰命名、如何依据顶层元素选择文件名、以及该规则如何在 IDE 静态检查流程中落地生效。读完本文你将能够正确命名仓颉.cj源文件并理解 cjlint 规则文档、规则 ID、检查级别与屏蔽注释之间的完整关联。规则速览项内容规则 IDG.NAM.02级别建议suggestions对应 cjlint 缺陷严重级别 severity1适用范围.cj源文件名核心要求源文件名使用全小写加下划线风格禁止使用驼峰命名规则文档tools-extension/cjlint/src/main/resources/docs/G_NAM_02.md该规则属于仓颉代码质量体系中的命名Naming类规则。仓库中完整规则文档集位于 tools-extension/cjlint/src/main/resources/docs/覆盖命名G_NAM、类G_CLS、常量G_CON、声明G_DCL、格式G_FMT、函数G_FUN等十余个类别共 80 条规则G.NAM.02 即其中一条面向文件名的规则。为什么文件名必须全小写加下划线跨平台大小写语义差异规则描述部分给出了这条命名约束的根本原因文件名不采用驼峰的原因是不同系统对文件名大小写处理不同如 Windows 系统不区分大小写但是 Unix/Linux、Mac 系统则默认区分。换句话说MyClass.cj在 Windows 上可能与myclass.cj指向同一个文件但在 Unix/Linux、macOS 上却被视为两个完全不同的文件。一旦项目在多平台间共享源码依赖大小写区分文件名的代码例如 import 路径、构建脚本中的文件引用就可能出现「本地能编译、CI 上找不到文件」的隐性故障。采用全小写 下划线的命名策略从源头规避了大小写语义差异带来的不确定性保证源码在任意文件系统上都能以一致的方式被解析。文件命名选择原则与顶层元素保持一致除了命名风格约束G.NAM.02 还给出了文件命名的内容依据如果文件只包含一个包外部可见的顶层元素那么直接选择该顶层元素的名称来命名文件否则包含多个顶层元素选择能代表主要内容的元素名称作为文件名。这里「顶层元素」包括包外部可见的类、函数、类型别名等。例如一个文件里只有一个public class MyClass文件名就应该是my_class.cj元素名MyClass转为全小写下划线形式而不是MyClass.cj。正例与反例规则文档给出了完整的示例代码此处完整保留正例文件名my_class.cj对应类名MyClass符合全小写加下划线风格// my_class.cj public class MyClass { // CODE }反例文件名MyClass.cj使用了驼峰命名不符合规范// MyClass.cj 文件名不符合使用了驼峰命名 public class MyClass { // CODE }正反例的差异点非常直观类名MyClass本身采用大驼峰这是 G.NAM.03 的要求见下文但文件名必须将其转换为全小写下划线形式my_class。与相邻命名规则的配合文件内命名 vs 文件名G.NAM.02 约束的是「文件名」而文件内部的标识符命名由其他规则约束二者需要配合使用。仓库规则文档集中与之相邻的几条命名规则均在 tools-extension/cjlint/src/main/resources/docs/ 下包括规则内容要点文档G.NAM.01包名全小写多单词用下划线分隔允许数字建议以 Internet 域名反转规则开头G_NAM_01.mdG.NAM.03接口、类、struct、enum 类型及构造器、类型别名采用大驼峰测试类推荐以被测试类名开头、以 Test 结尾G_NAM_03.mdG.NAM.04函数名称采用小驼峰如sendMessage、stopServer布尔属性建议加is/has前缀G_NAM_04.mdG.NAM.05const 变量采用下划线分隔的全大写单词命名G_NAM_05.mdG.NAM.06变量、属性、函数参数、pattern 采用小驼峰泛型类型参数允许单个大写字母或大写字母加数字G_NAM_06.md可以看到命名体系的分工是文件名用全小写下划线类型名用大驼峰函数/变量用小驼峰const 用全大写。文件my_class.cj中定义public class MyClass正是「文件名与内容元素一一对应」的典型写法。规则在 cjlint 静态检查中的落地实现G.NAM.02 不仅仅是一条书写规范它在 cangjie_deveco_plugins 仓库的cjlint 静态检查插件中拥有完整的工具链支撑。cjlint 是 tools-extension 下三个代码质量子插件之一cjformat 格式化、cjcov 覆盖率、cjlint 静态检查负责将上述规则文档作为检查依据落地到 IDE 中。规则 ID 与文档的自动映射cjlint 引擎在展示检查结果时会把缺陷的规则 ID 自动映射到对应的规则文档路径供开发者点击查看详细规范。这一逻辑实现在 CjlintCodeCheckCmd.java 的getRuleDocPath方法中String result description.substring(ZERO, description.indexOf(COLON)).replace(POINT, UNDER_LINE); docPath.append(DOCS).append(File.separator).append(result).append(MD_TYPE);即把描述中的规则 IDG.NAM.02中的.替换为_得到G_NAM_02再拼接.md后缀最终定位到 G_NAM_02.md。这正是仓库中规则文档按G_XXX_NN.md命名存放的原因——文档文件名与规则 ID 一一对应。级别映射建议级缺陷的严重程度G.NAM.02 的级别是「建议」。在 cjlint 的结果解析中CjlintCodeCheckCmd.java引擎从引擎输出 JSON 中读取defectLevel字段将suggestions级别映射为 severity1、mandatory级别映射为 severity2对应 IDE 问题面板中不同等级的告警展示。规则引擎的底层输出结构由 DefectInfo.java 定义包含defectLevel、file、description、defectType、line、column等字段。引擎注册与规则配置cjlint 通过 META-INF/cjlint.xml 将com.huawei.deveco.cjlint.CjlintEngine注册为com.huawei.codelinter扩展点的 engineProvider从而接入 IDE 的代码检查框架规则是否参与检查可由工程根目录下的cjlint_rule_list.json自定义其 JSON 映射类为 CjlintRuleListConfig.java字段ruleList配置文件键名为RuleList检查范围可由工程根目录下的code-linter.json5中的files与ignore字段控制映射类为 CodeLinterJson5Config.java其中ignore使用相对工程根目录的 glob 路径。相关筛选逻辑见 CjlintCodeCheckCmd.java规则 ID 的解析正则由 CodeCheckConstantUtil.java 定义^([A-Z_]{1,10}_\d{1,5})引擎名称固定为cjlint。屏蔽机制行级与整文件当某处确需例外时可以通过注释屏蔽缺陷。规则 IDG.NAM.02经 CjLintManager.java 的getIgnoreRule转换匹配规则 ID 前缀、将_还原为.并加!前缀得到!G.NAM.02配合 PsiHandler.java 中定义的注释格式使用单行/单点屏蔽在对应行添加注释// cjlint-ignore !G.NAM.02整文件屏蔽文件首行加// cjlint-ignore -start !G.NAM.02 ...文件末尾加// cjlint-ignore -end相关常量与逻辑见 PsiHandler.java 与 CjlintEngine.java 的shieldSelectedDefect/shieldDefect实现。实践建议总结命名规则仓颉.cj源文件一律使用全小写加下划线命名如my_class.cj、http_client.cj不使用驼峰内容对应文件仅含一个包外可见顶层元素时文件名取该元素名的全小写下划线形式含多个元素时取能代表主要内容的元素名跨平台一致性全小写下划线命名规避了 Windows 与 Unix/Linux、macOS 之间文件系统大小写语义差异导致的构建隐患工具联动规则文档G_NAM_02.md与规则 IDG.NAM.02一一对应可在 cjlint 检查结果中直接跳转查看如需调整检查范围可通过cjlint_rule_list.json、code-linter.json5与cjlint-ignore注释按需配置。赞分享开发工具IDE调试器代码质量【免费下载链接】cangjie_deveco_plugins项目地址https://gitcode.com/Cangjie/cangjie_deveco_plugins点击查看免费下载相关推荐仓颉包命名规范 G.NAM.01 全解析全小写下划线包名约定与 cjlint 静态检查落地仓颉包命名规范 G.NAM.01 全解析全小写下划线包名约定与 cjlint 静态检查落地 本文以仓颉Cangjie静态检查工具 cjlint 的规则文档开发工具IDE调试器代码质量仓颉函数命名规范 G.NAM.04小驼峰命名规则与 cjlint 静态检查实践仓颉函数命名规范 G.NAM.04小驼峰命名规则与 cjlint 静态检查实践 导读 本文围绕仓颉Cangjie编程规范条目 G.NAM.04「函数名称应开发工具IDE调试器代码质量CActor 代码风格指南仓颉语言 Actor 框架的命名、格式化与工程规范全解析CActor 代码风格指南仓颉语言 Actor 框架的命名、格式化与工程规范全解析 本文以 CActor 项目官方代码风格指南为核心系统讲解这套基于仓颉C后端并发编程分布式上一篇从论文到临床Multi-Agent Medical Assistant的PubMed与网络搜索集成方案下一篇3步实现Plyr播放器自适应布局从固定尺寸到全场景适配创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考