Carbon Language 命名规范：UpperCamelCase 与 lower_snake_case 的设计与实践

Carbon Language 命名规范UpperCamelCase 与 lower_snake_case 的设计与实践【免费下载链接】carbon-langCarbon Languages main repository: documents, design, implementation, and related tools. (NOTE: Carbon Language is experimental; see README)项目地址: https://gitcode.com/GitHub_Trending/ca/carbon-lang导读本文基于 Carbon Language 仓库中的提案 p000861-naming-conventions.md 及其被采纳后的设计文档 docs/design/naming_conventions.md系统梳理 Carbon 语言为“惯用法代码idiomatic code”与“语言自带功能Carbon-provided features”确立的命名规则。全文围绕“仅使用UpperCamelCase与lower_snake_case两种命名风格以编译期/运行期为分界”这一核心原则展开并结合仓库内 prelude 类型源码与官方示例帮助读者理解命名决策的来龙去脉并能在实际编写 Carbon 代码时直接套用这套规范。为什么需要一份命名规范提案的背景Carbon 是一个面向 C 后继者的实验性语言。在语言早期阶段团队希望编写文档和示例代码时就走上一条“合理一致”的道路因此通过提案proposal机制确立了命名约定其目标覆盖两类对象惯用法 Carbon 代码即普通开发者日常书写的函数、变量、类型等Carbon 自带功能包括关键字如fn、for、类型字面量如i32、类型如bool、String等由语言自身提供的能力。之所以通过正式提案而非临时约定来推进是为了确保早期文档与示例代码的一致性避免项目发展过程中出现风格分裂见 proposals/p000861-naming-conventions.md。跨语言先例命名约定是各语言风格指南中反复出现的话题。提案参考了多种语言提供的官方规范Effective Go 中的命名章节Python 的 PEP 8特别是其列出的多种命名风格清单Rust API Guidelines 中的命名要求Swift 的 API Design Guidelines 中的通用约定。这些先例的共同点是为不同的命名场景常量、变量、类型、函数等定义清晰、可记忆的规则降低阅读成本。关联议题与提案命名规范在仓库中并非孤立决策它与以下历史讨论直接相关Issue #543「pick names for fixed-size integer types」讨论定长整数类型的命名Issue #750「Naming conventions for Carbon-provided features」作为命名约定的初始讨论地提案 #720「Property naming in C」讨论属性命名的细节见 proposals/p000861-naming-conventions.md。提案核心只用两种命名风格提案给出的核心决策非常简洁Carbon 的命名约定只使用UpperCamelCase和lower_snake_case两种风格以此最小化规则变体减少开发者需要记忆的风格数量。划分两者的依据是命名对象的值是否在编译期可知UpperCamelCase用于“值不可能动态变化”的命名对象例如函数、命名空间namespace、编译期常量lower_snake_case用于“值要到运行期才可知”的命名对象例如变量。对于 Carbon 自带功能关键字keywords与类型字面量type literals使用lower_snake_case其余自带条目遵循惯用法代码的命名准则。各类条目的命名对照表提案用一张表格完整总结了各类条目的约定、原因见 proposals/p000861-naming-conventions.md亦被采纳进 docs/design/naming_conventions.md条目约定原因包PackagesUpperCamelCase用于编译期查找。类型TypesUpperCamelCase在编译期解析。函数FunctionsUpperCamelCase在编译期解析。方法MethodsUpperCamelCase方法包括虚方法与函数等价。泛型参数Generic parametersUpperCamelCase可能随输入变化但最终在编译期解析。编译期常量Compile-time constantsUpperCamelCase在编译期解析更多说明见下文“常量”一节。变量Variableslower_snake_case可能被重新赋值因此需要运行期信息。成员变量Member variableslower_snake_case与变量行为一致。关键字Keywordslower_snake_case特殊条目跨语言开发者普遍习惯这种大小写。类型字面量Type literalslower_snake_case与关键字等价。布尔类型与字面量Boolean type and literalslower_snake_case与关键字等价。其他 Carbon 类型Other Carbon typesUpperCamelCase与普通类型行为一致。Self与BaseUpperCamelCase类似类上的类型成员。需要特别说明的是虽然表中「其他 Carbon 类型」当前使用UpperCamelCase但不应据此推断未来的 Carbon 类型都会如此——未来命名将由 leads项目负责人按具体情况决策见 proposals/p000861-naming-conventions.md。常量怎么命名编译期可见性是分水岭提案假设let用于声明常量并给出了如下示例代码package Example; let CompileTimeConstant: i32 7; fn RuntimeFunction(runtime_constant: i32);这段代码展示了两种“常量”的差别CompileTimeConstant只有一个值7且该值在编译期已知因此使用UpperCamelCaseruntime_constant虽然可能在函数体内部不变但它是在RuntimeFunction被调用时于运行期赋值的其值只在某次具体的运行期调用中可知因此使用lower_snake_case。这一区分与 Carbon 的“表达式阶段expression phase”概念相互印证模板常量template constant与符号常量symbolic constant统称为编译期常量其值在编译期即可确定而运行期值runtime value只有动态值只能在运行时得知参见 docs/design/README.md。命名规范正是以这一阶段分界为命名依据。Carbon 自带条目的命名五类划分Carbon 自带条目被划分为五类见 proposals/p000861-naming-conventions.md关键字例如for、fn、var类型字面量例如idigits、udigits、fdigits即i32、u64、f64这类写法布尔类型与字面量例如bool、true、false。提案特别强调将布尔单独归类不应被理解成“只有布尔才能用小写”它只是当前唯一的例子Self与Base其他 Carbon 类型例如Int、UInt、String。仓库源码中的佐证这套分类在当前仓库的 prelude预置库源码中有直观体现。以bool为例它在 core/prelude/types/bool.carbon 中通过内建函数构造类型package Core library prelude/types/bool; private fn MakeBool() - type bool.make_type; alias Bool MakeBool();注意上层的Bool别名遵循“其他 Carbon 类型”的UpperCamelCase约定而设计文档明确指出bool、true、false本身是关键字见 docs/design/README.md。再以Int为例core/prelude/types/int.carbon 中class Int(N: IntLiteral)使用UpperCamelCase定义泛型类而i32、i64这类具体的类型字面量则写成lower_snake_case。同样String在 core/prelude/types/string.carbon 中以class String { ... }定义属于“其他 Carbon 类型”的UpperCamelCase范畴而预置目录 core/prelude/types 下的文件命名bool.carbon、int.carbon、string.carbon、uint.carbon等也整体遵循小写风格。规范在真实示例代码中的落地仓库中的官方示例直接体现了上述约定。以 examples/sieve.carbon埃拉托色尼筛法为例class Sieve { impl as Core.UnformedInit {} fn Make() - Sieve { returned var s: Sieve; for (n: i32 in Core.Range(1000)) { s.is_prime[n] true; } return var; } fn MarkMultiplesNotPrime(ref self, p: i32) { ... } var is_prime: array(bool, 1000); } fn Run() - i32 { var s: Sieve Sieve.Make(); var number_of_primes: i32 0; ... }对照命名表可以逐项验证类型Sieve、函数Make/MarkMultiplesNotPrime/Run均使用UpperCamelCase成员变量is_prime、局部变量s、n、number_of_primes均使用lower_snake_case类型字面量i32、关键字bool、var、for均为lower_snake_case。再如 examples/hello_world.carbonimport Core library io; fn Run() { Core.PrintStr(Hello world!\n); }fn是关键字、Run是函数UpperCamelCase、Core是包UpperCamelCase与提案分类完全一致。设计动机与 Carbon 项目目标的一致性提案从 Carbon 的项目目标出发给出了两点理由见 proposals/p000861-naming-conventions.md对应目标原文见 docs/project/goals.md代码易于阅读、理解和编写限定为UpperCamelCase与lower_snake_case两种风格开发者只需学习极少数规则同时保持良好的书写手感ergonomics与既有 C 代码的互操作及迁移希望在与 C 的命名一致性上保持亲近这一点从关键字for以及布尔字面量沿用 C 风格即可看出。备选方案与历史决策被否定的其他命名风格提案讨论并否决了两种备选风格lowerCamelCase对于单标识符single-word identifiers而言它与lower_snake_case难以区分而UpperCamelCase与lower_snake_case无论单词个数多少都边界清晰ALL_CAPS_SNAKE_CASEC 中常用于宏和编译期常量。Carbon 希望语言足够简单让“额外一种命名风格带来的可读性收益”不值得“开发者多学一套规则”的成本。关于 Carbon 类型命名的细化决策提案逐个记录了针对具体命名的讨论结论类型字面量用lower_snake_case源于 Issue #543i8比Int8更简洁、书写更省力i32、i64与 C 的int长度相当不采用I32因为I32在视觉上难以与132、l32区分即便它可能对屏幕阅读器更友好。布尔值用bool、true、false主要出于不偏离 C 的考虑。leads 允许Self、Base等名称被遮蔽shadowing但不允许遮蔽布尔条目。Self与Base使用UpperCamelCaseleads 希望它们看起来更像普通类型。实现上可能采用混合方案——类似于类中的查找既不算严格关键字又因 leads 可能拒绝在非类上下文中把它们用作标识符而带有关键字的色彩。String等其他名字遵循惯用法命名此处接受了与 C 的差异。两个整体性备选方案综合上述考量关键字与类型字面量大概率保持lower_snake_case提案还讨论了主要影响self、base、string的两个备选凡是语言自带且无需import的条目一律lower_snake_case例如i32、bool、true、self、base、string.is_empty()如上但 prelude 类成员遵循标准命名例如i32、bool、true、self、base、string.IsEmpty()。最终理解是bool被当作类关键字、Self被当作类类型无论底层如何实现之间的差异带有一定随意性。不统一使用lower_snake_case的决定主要取决于 leads 的倾向——self和base不应被严格当作关键字而string则是用户应当期待“更像惯用类”的分界点。未来出现边界情况时将由 leads 决定其更偏向关键字还是类型完整讨论见 proposals/p000861-naming-conventions.md。遗留问题提案文本中「Open questions」一节当时为空即命名规范在提案通过时已无悬而未决的公开问题。此后该规范的后续演进例如Self/Base的类成员实现、新类型字面量的命名通过新的提案与 leads 决策持续推进可参考 docs/design/naming_conventions.md 中维护的最新版本。小结Carbon 的命名规范可以浓缩为一句口诀编译期可知用UpperCamelCase运行期可知用lower_snake_case关键字与类型字面量一律小写Self/Base特殊对待其余类型按普通类型命名。这一规范已被正式采纳进 docs/design/naming_conventions.md并在 prelude 源码core/prelude/types与官方示例examples/sieve.carbon、examples/hello_world.carbon中持续落地。阅读该提案的完整讨论可进一步追踪Self、Base、string等边界条目的历史决策以及它对文档编写和示例代码风格的长远影响。【免费下载链接】carbon-langCarbon Languages main repository: documents, design, implementation, and related tools. (NOTE: Carbon Language is experimental; see README)项目地址: https://gitcode.com/GitHub_Trending/ca/carbon-lang创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考