开发工具IDE调试器代码质量【免费下载链接】cangjie_deveco_plugins项目地址https://gitcode.com/Cangjie/cangjie_deveco_plugins点击查看免费下载G.FMT.12 是仓颉Cangjie编码规范中关于「修饰符关键字书写顺序」的核心规则它规定public/protected/private、open/abstract/static/sealed、override/redef、unsafe/foreign、const/mut五组修饰符必须按照固定的优先级从前到后排列并额外强调sealed与public/open的互斥关系。本文基于开源仓库 cangjie_deveco_plugins 中 cjlint 静态检查工具内置的规则文档完整解读该规则的优先级模型、语义背景与正反示例并结合插件源码说明该规则如何被 cjlint 引擎识别、定级、报告与屏蔽帮助开发者在 DevEco Studio 仓颉插件环境中写出符合规范、可被工具自动校验的代码。规则速览优先级分组与适用级别规则文档位于 G_FMT_12.md其核心内容非常明确规则编号G.FMT.12属于FMT格式类规则族级别建议suggestion即推荐性约束不构成强制要求描述修饰符关键字必须按照统一的优先级顺序排列推荐顺序如下public/protected/private open/abstract/static/sealed override/redef unsafe/foreign const/mut这条优先级链从左到右、从上到下依次递减访问控制public/protected/private拥有最高优先级其次是与继承、抽象、静态化、封闭性相关的修饰符再次是覆写类修饰符然后是安全与外部声明修饰符最后是常量/可变性修饰符。一个声明上同时出现的多个修饰符应严格按照该顺序书写。从源码角度看cjlint 插件为每条规则维护了独立的 Markdown 文档src/main/resources/docs/目录下共 80 余个规则文件G_FMT_12.md即其中之一。规则文档中的【级别】字段会直接影响问题在 IDE 检查面板中的严重程度映射在 CjlintCodeCheckCmd.java 中定义了SUGGESTIONS_SEVERITY 1与MANDATORY_SEVERITY 2两个常量getInfo()方法将检查工具输出中的suggestions建议级别映射为严重度 1将mandatory要求级别映射为严重度 2。因此违反 G.FMT.12 的问题会以「建议」级severity 1展示而像 G_FMT_01.md强制 UTF-8 编码这类「要求」级规则则以更高严重度展示。修饰符分组与语义背景理解优先级排序的前提是理解每一组修饰符在仓颉语言中的作用与它们之间的层次关系。第一组访问控制 ——public/protected/private这是所有修饰符中优先级最高的一组控制声明的可见范围。三者互为互斥选项一个成员或类型声明通常只选取其一。仓颉规范中多处体现了「访问修饰符从大到小排列」的一致原则例如 G_FMT_04.md 明确要求类内部成员按public、protected、private的顺序组织声明。G.FMT.12 将其置于优先级链最前端意味着无论声明中出现哪些其他修饰符访问控制词都必须最先出现public open class Animal { ... } // 符合public 在 open 之前 protected static let count: Int64 0 // 符合protected 在 static 之前第二组继承与静态化 ——open/abstract/static/sealed这一组修饰符与类型的继承体系、成员绑定方式及封闭性相关open允许类型被继承扩展abstract抽象声明本身不含完整实现static静态成员绑定于类型而非实例sealed封闭类型只允许在同一编译单元内被继承。它们统一排在访问控制之后。从仓库示例代码可以看到G_CLS_02.md 中大量使用了private static const、public static func、sealed interface I1等组合写法均严格遵循「访问控制 → static/sealed」的次序。第三组覆写 ——override/redefoverride与redef分别用于实例方法与静态成员的覆写/重定义场景二者处于同一优先级层级。它们必须排在访问控制与继承类修饰符之后例如 G_FMT_11.md 示例中出现的override func onCreate(): Unit前面可以再叠加访问控制词public override func describe(): String { ... } // 符合public → override第四组安全与外部声明 ——unsafe/foreignunsafe与不安全代码操作相关foreign则用于声明外部FFI函数。该仓库的 cjlint 规则集中设有独立的 FFI_C_1.md 至 FFI_C_7 系列文档专门约束外部函数接口的书写足见 FFI 场景在仓颉开发中的重要性。当这类修饰符与其他修饰符同现时必须排在第三组之后。第五组常量与可变性 ——const/mutconst声明常量不可变mut声明可变性。它们是优先级最低的一组永远位于修饰符链的末尾public const MAX_SIZE: Int64 1024 // 符合const 排在最后 private mut var offset: Int64 0 // 符合mut 排在最后sealed 与 public/open 的互斥约定规则文档在给出优先级链之外还专门强调了一条补充约定因为sealed已经蕴含了public和open的语义不推荐sealed与public或open同时使用。也就是说sealed类型天然具备对外可见public与可被扩展open的双重语义再显式叠加public或open不仅冗余还会造成语义混乱。以下写法均不符合规范sealed public class Shape { } // 不符合sealed 已蕴含 public open sealed class Circle { } // 不符合sealed 已蕴含 open正确做法是直接使用sealed单独修饰sealed class Shape { // 符合自带 public open 语义 public func area(): Float64 { ... } }这一约定也解释了为什么优先级链中sealed与open/abstract/static同组它们在语义上属于同一抽象层次sealed实际上是「封闭 开放 可见」的组合形态。正反例对照从错误写法到规范写法综合上述分组规则下面给出完整的正反例对照帮助快速掌握修饰符的正确排布。反例不符合 G.FMT.12static public func create(): Util { } // 不符合public 应排在 static 之前 const public let LIMIT: Int64 10 // 不符合public 应排在 const 之前 sealed public class Shape { } // 不符合sealed 蕴含 public不可同时使用 open sealed class Circle { } // 不符合sealed 蕴含 open foreign unsafe func c_func(): Unit { } // 不符合unsafe 应先于 foreign第四组内正例符合 G.FMT.12public static func create(): Util { } // public → static public const LIMIT: Int64 10 // public → const public open class Shape { } // public → open sealed class Circle { } // sealed 单独使用 public override func toString(): String { return ... } // public → override public unsafe func process(): Unit { ... } // public → unsafe记忆口诀很简单先看可见性public/protected/private再看继承静态封闭open/abstract/static/sealed随后是覆写override/redef、安全外部unsafe/foreign最后才是常量可变const/mut。规则落地cjlint 如何承载与报告 G.FMT.12G.FMT.12 不是一条孤立的文档规范它由 cjlint 静态检查工具实际落地执行。cjlint 是 tools-extension 中的三个子插件之一与 cjformat 格式化、覆盖率检查并列其插件描述文件 cjlint.xml 通过以下方式完成引擎注册extensions defaultExtensionNscom.huawei.codelinter engineProvider implementationcom.huawei.deveco.cjlint.CjlintEngine/ /extensions dependscom.huawei.codelinter/depends围绕这条规则的工程化实现可以梳理出四条关键链路规则文档定位检查结果中每条缺陷都带有规则描述如G.FMT.12: ...。CjlintCodeCheckCmd.getRuleDocPath() 截取描述中冒号前的规则号、将.替换为_拼接出docs/G_FMT_12.md路径供 IDE 面板一键跳转到规则原文CjlintEngine.getRuleDocPath() 则负责将相对路径解析为插件lib/cjlint目录下的绝对路径。严重度映射DefectInfoDefectInfo.java承载检查工具输出的defectLevel、defectType、line、column等字段getInfo()将suggestions映射为严重度 1。由于 G.FMT.12 是「建议」级命中后不会阻塞构建仅作为提示展示。行级屏蔽ignore开发者可通过在代码行添加// cjlint-ignore !G.FMT.12注释屏蔽该条问题。CjLintManager.getIgnoreRule() 借助 CodeCheckConstantUtil.java 中的正则^([A-Z_]{1,10}_\d{1,5})提取规则号G_FMT_12并转换为!G.FMT.12CjlintEngine 中的CJLINT_IGNORE_MATCHER则负责识别已有注释并支持追加规则。规则集裁剪工程根目录可通过自定义cjlint_rule_list.json对应映射类 CjlintRuleListConfig.java与exclude_lists.json替换默认规则集通过code-linter.json5对应映射类 CodeLinterJson5Config.java的files/ignore配置限定检查范围这些逻辑由 CjlintCodeCheckCmd.processCustomizedCJLintConfigs() 与filterResultListByCodeLinterJson5()统一处理。与同类 FMT 规则的协同使用G.FMT.12 属于FMT格式规则族与该族的其他规则共同构成仓颉代码格式的整体约束规则主题与本规则的关系G_FMT_04.md类成员声明顺序、访问修饰符从大到小与本规则的修饰符优先级互相印证G_FMT_10.md空格突出关键字与重要信息关注修饰符与后续 token 之间的空格G_FMT_11.md减少不必要空行关注声明块之间的空行排版G_FMT_13.md文件头版权许可注释修饰符规则适用于版权注释之后的正式代码以 G_FMT_04.md 为例它规定实例变量与构造函数按public、protected、private排列这与 G.FMT.12 中访问控制组拥有最高优先级的设计一脉相承先确定成员被谁可见再决定它是否开放、是否静态、如何覆写、能否变更。实践中建议将 G.FMT.12 与上述规则一并纳入检查配置让格式问题在编码阶段即被 IDE 提示减少代码评审中反复「改写法」的沟通成本。小结G.FMT.12 用一张五层优先级链统一了仓颉代码中修饰符的书写次序public/protected/private→open/abstract/static/sealed→override/redef→unsafe/foreign→const/mut并明确规定sealed不再与public/open联用。该规则以「建议」级别内置于 cjlint 静态检查工具的规则集G_FMT_12.md通过 CjlintEngine.java 与 CjlintCodeCheckCmd.java 完成报告、定级与屏蔽。遵循这一优先级不仅能让声明行一眼可读、降低多修饰符组合时的认知负担也能让代码通过静态检查工具的自动校验与仓颉社区的整体风格保持一致。赞分享开发工具IDE调试器代码质量【免费下载链接】cangjie_deveco_plugins项目地址https://gitcode.com/Cangjie/cangjie_deveco_plugins点击查看免费下载相关推荐仓颉源文件编码规范 G.FMT.01 详解UTF-8 强制要求与 cjlint 静态检查落地实践仓颉源文件编码规范 G.FMT.01 详解UTF 8 强制要求与 cjlint 静态检查落地实践 导读 G.FMT.01 是仓颉Cangjie编程语言静态开发工具IDE调试器代码质量仓颉编码规范 G.FMT.07 实战指南一行只有一个声明或表达式cjlint 静态检查仓颉编码规范 G.FMT.07 实战指南一行只有一个声明或表达式cjlint 静态检查 本指南围绕仓颉Cangjie代码质量工具 cjlint 的格式开发工具IDE调试器代码质量仓颉代码规范 G.FMT.06 详解表达式中不要插入空白行兼析 cjlint 静态检查的规则落地机制仓颉代码规范 G.FMT.06 详解表达式中不要插入空白行兼析 cjlint 静态检查的规则落地机制 导读 本篇技术指南围绕 DevEco Studio 仓开发工具IDE调试器代码质量上一篇SVGR将 SVG 转换为 React 组件的通用工具 —— 从零到生产级实践指南下一篇Hyperledger Fabric 依赖的 go-logfmt 库logfmt 结构化日志格式的 API 演进与源码实现解析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
