Carbon Language 代码风格与格式化指南pre-commit 多语言工具链与规范实践【免费下载链接】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-langCarbon Language 主仓库是一个以 C 实现编译器Toolchain为核心、同时包含 Bazel 构建配置、Python 工具脚本与大量 Markdown 文档的混合型代码库。本指南围绕仓库内.agents/skills/code_style/SKILL.md这份代码风格技能卡展开系统讲解 Carbon 项目对 License 头、各语言格式化命令、风格指南的明确要求并结合仓库内真实的 pre-commit 配置.pre-commit-config.yaml、C 风格指南docs/project/cpp_style_guide.md与贡献规范CONTRIBUTING.md进行纵深剖析。阅读本文后你将掌握在 Carbon 仓库中提交代码前需要执行的格式化与风格检查命令理解 Bazel、C、Carbon、Markdown、Python 五种类型文件各自的格式化工具选择与配置细节并了解这些规范背后的设计动机。一、总览一份面向工具链代码的风格技能卡.agents/skills/code_style/SKILL.md是 Carbon 仓库为 AI 助手与人类贡献者准备的技能说明其定位非常明确为 Carbon 工具链中的代码格式化与风格规范提供统一指令。它虽然篇幅不长但覆盖了三条主线License 合规除third_party/外所有 Carbon 文件都必须携带统一格式的许可证头格式化命令针对 Bazel、C、Carbon、Markdown、Python 五种文件类型分别给出通过 pre-commit 调用的格式化命令风格指南C 遵循项目自有的 C 风格指南Markdown 遵循 Google 开发者文档风格指南Python 遵循 PEP 8。值得注意的是Carbon 语言自身的format命令目前工作得还不好文档原文为 doesnt work well right now因此 Carbon 代码的格式化暂时依赖人工参照其他 Carbon 文件与 C 风格完成。这一点从仓库结构中可以印证toolchain/format/目录虽然存在内含 7 个.carbon源文件与若干 C 头/实现文件但尚未成为主流的格式化途径。二、License 头要求所有文件的身份证SKILL.md 对 License 的要求非常明确Licenses所有位于third_party/之外的 Carbon 文件都应按照 CONTRIBUTING license instructions 携带许可证声明。仓库根目录的 CONTRIBUTING.md 进一步细化了这一规则Markdown 文件顶部必须包含标题与固定注释块例如CONTRIBUTING.md自身顶部即为# DOC TITLE !-- Part of the Carbon Language project, under the Apache License v2.0 with LLVM Exceptions. See /LICENSE for license information. SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception --其他文件类型每种文件类型使用相同 License 文本Apache-2.0 WITH LLVM-exception的变体但注释语法不同。这一规则在 .pre-commit-config.yaml 的check-copyright钩子中有完整落地它针对.carbon、.c、.json、.scss、.ypp使用//注释、.js/.ts/.mjs使用/* */、.l/.lpp/.y、.plist/.tmLanguageHTML 注释、.vim注释、.scm;注释、.lua--注释等分别配置了自定义格式并排除了LICENSE.*、third_party/.*、.def、.png、.svg、fuzzer 语料与 golden 测试数据等特殊文件。为什么统一 License 这么重要Carbon 工具链会直接编译为 LLVM IR 并与 LLVM/Clang 深度集成仓库bazel/llvm_project/中即包含多个针对 LLVM 的 Bazel 构建补丁。为了保证整个编译器和运行库的依赖链 License 纯净仓库在 C 风格指南中明确规定不得给任何可能被编译器或运行时使用的代码引入其他第三方库依赖其动机正是所有传递依赖都希望处于 LLVM 许可之下。统一的 License 头检查因此成为合规的第一道防线。三、格式化命令基于 pre-commit 的五条工作流SKILL.md 的核心实操价值在于一组可以直接执行的格式化命令全部通过pre-commit run hook --files file模式调用。下表完整罗列文件类型命令格式化工具Bazelpre-commit run buildifier --files file.bzlbuildifierCpre-commit run clang-format --files file.cppclang-formatCarbon工具链format命令暂不可用参照其他 Carbon 文件与 C 风格人工格式化无Markdownpre-commit run prettier --files file.mdprettierPythonpre-commit run black --files file.pyblack3.1 背后的真实配置pre-commit 钩子全景这些命令并非虚构而是与 .pre-commit-config.yaml 中定义的钩子一一对应。该配置文件呈现了 Carbon 完整的多阶段检查流水线理解它能帮你更准确地使用格式化命令builtin 基础检查check-added-large-files、check-case-conflict、check-merge-conflict、check-yaml、detect-private-key、end-of-file-fixer、mixed-line-ending强制 LF排除 fuzzer 语料与.svg、trailing-whitespace等Markdown 专属rumdlMarkdown 规范检查器带--fix参数会运行两次以在风格检查与 TOC 生成后再次修复与check-google-doc-styleGoogle 文档风格检查显式排除.agents/与AGENTS.md、markdown-tocBazel 专属buildifier钩子实际调用仓库脚本 scripts/run_buildifier.py带--lintfix --warningsall参数——也就是说 SKILL.md 中的 buildifier 命令不只是格式化还会修复 lint 告警随后check-bazel-mod-deps会在 buildifier 修改输入后校验 MODULE.bazel 依赖因为MODULE.bazel.lock包含行列号信息C 专属clang-format钩子以-i就地修改方式运行锁定clang-format21.1.8版本作用于.cpp、.h与.def文件clang-format之后紧接check-header-guards检查头文件保护符见 scripts/check_header_guards.py另有fix-cc-deps自动补齐 C 依赖见 scripts/fix_cc_deps.pyPython 专属新版配置中实际使用 ruffruff-check --fix与ruff-format作为主力格式化/检查工具同时还有ty类型检查、codespell拼写检查等钩子项目特定检查check-proposal-names、check-sha-filenames、build-textmate-grammar基于 utils/vscode/carbon.tmLanguage.json 重新生成 TextMate 语法、check-toolchain-diagnostics、check-build-graph、forbid-llvm-googletest等。配置头部还给出了版本维护方式pre-commit autoupdate --freeze pre-commit run -a。同时注意default_language_version将 Python 显式固定为python3pre-commit 默认值为 python2这是一个容易踩的坑。3.2 只格式化指定文件--files 参数的价值SKILL.md 中所有命令都强调--files file限定范围。这在 Carbon 仓库场景下尤其实用toolchain/下有上千个测试语料文件如toolchain/check/testdata/约 980 个文件、toolchain/lex/语料 1300对全仓直接跑格式化会非常缓慢且可能触碰不应改动的测试数据。pre-commit 的--files参数允许只针对本次改动涉及的文件执行钩子与 CI 中仅检查变更文件的策略保持一致。3.3 Carbon 文件如何格式化SKILL.md 明确指出 Carbon 语言自身的format命令目前不可用因此给出两条替代策略参照其他 Carbon 文件仓库中core/prelude/标准库、examples/示例程序、toolchain/format/等目录积累了风格一致的 Carbon 代码可作为范本参照 C 风格Carbon 的 C 风格指南刻意向拟议中的 Carbon 命名规范靠拢见下文因此 C 的排版习惯与 Carbon 高度相似可作参照。四、风格指南三套规范体系4.1 CCarbon C Project Style GuideC 风格基线是Google C Style Guide其上加一层 Carbon 本地化约束完整内容见 docs/project/cpp_style_guide.md。几个最值得关注的点命名规则已知编译期常量、类型、函数、模板参数、constexpr变量、枚举值等使用UpperCamelCase仅做返回数据成员引用/赋值的成员函数含set_前缀方法可使用snake_case其余名字参数、非 const 局部与成员变量一律snake_case私有成员变量带尾随_。缩写词遵循 Google 的大小写习惯如Api而非API唯二例外是LLVM与IR文件命名一律snake_case同时避免-源文件用.cpp语法细节函数一律使用尾置返回类型包括- void为与 Carbon 语法保持一致指针*紧贴类型名TypeName* variable_nameconst放类型前const int N 42;用using而非typedef不使用using std::vector;这类非限定查找std::显式限定可带来更清晰的诊断并规避 ADL 歧义std::swap这类故意走 ADL 的除外构造函数默认explicit条件/循环语句一律加花括号内部链接优先用static而非匿名命名空间匿名命名空间保留给类与枚举测试代码是例外行注释只允许//且独占一行禁止行尾追加注释dont comment here 反例允许的例外是}的 closing namespace 注释与参数名注释初始化直接赋值用聚合初始化struct/pair/init-list优先花括号并尽量用 designated initializers{.a 1}带构造函数类型用圆括号FooType foo(10);auto花括号初始化被禁止auto a {0, 1}不行地址传递传对象地址时优先引用参数可选或需要超过调用表达式生命周期时用指针并注释空值约定auto使用局部变量普遍使用auto但bool/int等原始类型与较短的具名类型如SemIR::InstId可以显式写出数据结构的选型工具链内优先 LLVM 库与数据结构针对无异常、编译器场景深度优化过不引入第三方库依赖迭代优先明确选择迭代而非递归算法clang-tidy 辅助强制因为编译器要面对代码生成器等对调用栈压力极大的场景迭代在性能与健壮性上更优格式化落地文末指向仓库根目录的 .clang-format 文件即建议的.clang-format内容就是仓库实际使用的配置。4.2 MarkdownGoogle developer documentation style guideMarkdown 风格遵循 Google developer documentation style guide。从 CONTRIBUTING.md 可以补充几个 Carbon 特有的本地化约定用双连字符加空格text -- text替代 em dash因为项目经常在等宽字体下阅读 Markdownem dash 不清晰提到编写 Carbon 代码的人时统一用 developers 一词以覆盖软件开发者、系统工程师、数据科学家等各种自我定位。在工具层面.pre-commit-config.yaml 中的rumdlMarkdown 规范检查--fix与check-google-doc-style钩子负责自动执行。注意check-google-doc-style显式排除了.agents/目录与AGENTS.md即本文所讲的技能卡文档本身不参与该项检查。4.3 PythonPEP 8 与 80 列Python 风格遵循 PEP 8SKILL.md 额外强调两条硬性要求代码与注释折行到 80 列用pre-commit run flake8 --files file.py检查 Python 风格。从仓库现状看Python 生态已演进为 ruff 主导pyproject.toml与.pre-commit-config.yaml中的ruff-check/ruff-format承担了 flake8 的角色ty承担类型检查。仓库中的 Python 脚本如 scripts/run_buildifier.py、scripts/run_bazelisk.py 等均带完整 docstring 与类型注解可视为 80 列与 PEP 8 风格的活样例。五、实操建议把规范嵌入日常工作流结合技能卡与仓库实际推荐贡献者按如下顺序使用这些命令提交前pre-commit install安装 git 钩子后pre-commit run --files 本次改动的文件列表针对变更文件执行全部相关钩子需要单独修某类格式时使用 SKILL.md 给出的pre-commit run hook --files file精确触发Bazel 文件pre-commit run buildifier --files file.bzl实际执行 scripts/run_buildifier.py含 lint 修复C 文件pre-commit run clang-format --files file.cpp随后让check-header-guards校验头文件保护符Markdown 文件pre-commit run prettier --files file.md并留意rumdl与 Google 文档风格检查Python 文件pre-commit run black --files file.py或直接使用配置中的 ruff保持 80 列折行Carbon 文件先运行bazelisk run //toolchain -- format file.carbon验证当前format命令的实际表现若不可用则参照 core/prelude/ 与 examples/ 中的既有代码风格手工排版。全仓级别的完整自检可执行pre-commit run -a但考虑到toolchain/下海量测试语料与pre-commit autoupdate --freeze的版本冻结流程日常开发仍建议以--files定向运行为主。六、小结Carbon 的代码风格体系可以概括为单一来源、工具强制、语言自洽License 合规由check-copyright统一把关格式化统一收敛到 pre-commit 钩子buildifier、clang-format、prettier、black/ruff风格规范则由 C 风格指南这一主文档统摄并通过.clang-format落地执行。值得注意的是Carbon 的 C 风格有意向 Carbon 语言自身的拟议命名规范靠拢——从尾置返回类型到 designated initializers、从UpperCamelCase到snake_case都体现了用 C 代码预演 Carbon 习惯的 dogfooding 思路。对任何参与 Carbon 开发无论人类还是 AI 助手的贡献者而言掌握.agents/skills/code_style/SKILL.md中这套命令与规范是保证提交质量、降低评审摩擦的第一步而仓库根目录的 AGENTS.md 与 CONTRIBUTING.md 则提供了更完整的项目上下文与贡献流程。【免费下载链接】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），仅供参考 Carbon Language 代码风格与格式化指南：pre-commit 多语言工具链与规范实践
Carbon Language 代码风格与格式化指南pre-commit 多语言工具链与规范实践【免费下载链接】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-langCarbon Language 主仓库是一个以 C 实现编译器Toolchain为核心、同时包含 Bazel 构建配置、Python 工具脚本与大量 Markdown 文档的混合型代码库。本指南围绕仓库内.agents/skills/code_style/SKILL.md这份代码风格技能卡展开系统讲解 Carbon 项目对 License 头、各语言格式化命令、风格指南的明确要求并结合仓库内真实的 pre-commit 配置.pre-commit-config.yaml、C 风格指南docs/project/cpp_style_guide.md与贡献规范CONTRIBUTING.md进行纵深剖析。阅读本文后你将掌握在 Carbon 仓库中提交代码前需要执行的格式化与风格检查命令理解 Bazel、C、Carbon、Markdown、Python 五种类型文件各自的格式化工具选择与配置细节并了解这些规范背后的设计动机。一、总览一份面向工具链代码的风格技能卡.agents/skills/code_style/SKILL.md是 Carbon 仓库为 AI 助手与人类贡献者准备的技能说明其定位非常明确为 Carbon 工具链中的代码格式化与风格规范提供统一指令。它虽然篇幅不长但覆盖了三条主线License 合规除third_party/外所有 Carbon 文件都必须携带统一格式的许可证头格式化命令针对 Bazel、C、Carbon、Markdown、Python 五种文件类型分别给出通过 pre-commit 调用的格式化命令风格指南C 遵循项目自有的 C 风格指南Markdown 遵循 Google 开发者文档风格指南Python 遵循 PEP 8。值得注意的是Carbon 语言自身的format命令目前工作得还不好文档原文为 doesnt work well right now因此 Carbon 代码的格式化暂时依赖人工参照其他 Carbon 文件与 C 风格完成。这一点从仓库结构中可以印证toolchain/format/目录虽然存在内含 7 个.carbon源文件与若干 C 头/实现文件但尚未成为主流的格式化途径。二、License 头要求所有文件的身份证SKILL.md 对 License 的要求非常明确Licenses所有位于third_party/之外的 Carbon 文件都应按照 CONTRIBUTING license instructions 携带许可证声明。仓库根目录的 CONTRIBUTING.md 进一步细化了这一规则Markdown 文件顶部必须包含标题与固定注释块例如CONTRIBUTING.md自身顶部即为# DOC TITLE !-- Part of the Carbon Language project, under the Apache License v2.0 with LLVM Exceptions. See /LICENSE for license information. SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception --其他文件类型每种文件类型使用相同 License 文本Apache-2.0 WITH LLVM-exception的变体但注释语法不同。这一规则在 .pre-commit-config.yaml 的check-copyright钩子中有完整落地它针对.carbon、.c、.json、.scss、.ypp使用//注释、.js/.ts/.mjs使用/* */、.l/.lpp/.y、.plist/.tmLanguageHTML 注释、.vim注释、.scm;注释、.lua--注释等分别配置了自定义格式并排除了LICENSE.*、third_party/.*、.def、.png、.svg、fuzzer 语料与 golden 测试数据等特殊文件。为什么统一 License 这么重要Carbon 工具链会直接编译为 LLVM IR 并与 LLVM/Clang 深度集成仓库bazel/llvm_project/中即包含多个针对 LLVM 的 Bazel 构建补丁。为了保证整个编译器和运行库的依赖链 License 纯净仓库在 C 风格指南中明确规定不得给任何可能被编译器或运行时使用的代码引入其他第三方库依赖其动机正是所有传递依赖都希望处于 LLVM 许可之下。统一的 License 头检查因此成为合规的第一道防线。三、格式化命令基于 pre-commit 的五条工作流SKILL.md 的核心实操价值在于一组可以直接执行的格式化命令全部通过pre-commit run hook --files file模式调用。下表完整罗列文件类型命令格式化工具Bazelpre-commit run buildifier --files file.bzlbuildifierCpre-commit run clang-format --files file.cppclang-formatCarbon工具链format命令暂不可用参照其他 Carbon 文件与 C 风格人工格式化无Markdownpre-commit run prettier --files file.mdprettierPythonpre-commit run black --files file.pyblack3.1 背后的真实配置pre-commit 钩子全景这些命令并非虚构而是与 .pre-commit-config.yaml 中定义的钩子一一对应。该配置文件呈现了 Carbon 完整的多阶段检查流水线理解它能帮你更准确地使用格式化命令builtin 基础检查check-added-large-files、check-case-conflict、check-merge-conflict、check-yaml、detect-private-key、end-of-file-fixer、mixed-line-ending强制 LF排除 fuzzer 语料与.svg、trailing-whitespace等Markdown 专属rumdlMarkdown 规范检查器带--fix参数会运行两次以在风格检查与 TOC 生成后再次修复与check-google-doc-styleGoogle 文档风格检查显式排除.agents/与AGENTS.md、markdown-tocBazel 专属buildifier钩子实际调用仓库脚本 scripts/run_buildifier.py带--lintfix --warningsall参数——也就是说 SKILL.md 中的 buildifier 命令不只是格式化还会修复 lint 告警随后check-bazel-mod-deps会在 buildifier 修改输入后校验 MODULE.bazel 依赖因为MODULE.bazel.lock包含行列号信息C 专属clang-format钩子以-i就地修改方式运行锁定clang-format21.1.8版本作用于.cpp、.h与.def文件clang-format之后紧接check-header-guards检查头文件保护符见 scripts/check_header_guards.py另有fix-cc-deps自动补齐 C 依赖见 scripts/fix_cc_deps.pyPython 专属新版配置中实际使用 ruffruff-check --fix与ruff-format作为主力格式化/检查工具同时还有ty类型检查、codespell拼写检查等钩子项目特定检查check-proposal-names、check-sha-filenames、build-textmate-grammar基于 utils/vscode/carbon.tmLanguage.json 重新生成 TextMate 语法、check-toolchain-diagnostics、check-build-graph、forbid-llvm-googletest等。配置头部还给出了版本维护方式pre-commit autoupdate --freeze pre-commit run -a。同时注意default_language_version将 Python 显式固定为python3pre-commit 默认值为 python2这是一个容易踩的坑。3.2 只格式化指定文件--files 参数的价值SKILL.md 中所有命令都强调--files file限定范围。这在 Carbon 仓库场景下尤其实用toolchain/下有上千个测试语料文件如toolchain/check/testdata/约 980 个文件、toolchain/lex/语料 1300对全仓直接跑格式化会非常缓慢且可能触碰不应改动的测试数据。pre-commit 的--files参数允许只针对本次改动涉及的文件执行钩子与 CI 中仅检查变更文件的策略保持一致。3.3 Carbon 文件如何格式化SKILL.md 明确指出 Carbon 语言自身的format命令目前不可用因此给出两条替代策略参照其他 Carbon 文件仓库中core/prelude/标准库、examples/示例程序、toolchain/format/等目录积累了风格一致的 Carbon 代码可作为范本参照 C 风格Carbon 的 C 风格指南刻意向拟议中的 Carbon 命名规范靠拢见下文因此 C 的排版习惯与 Carbon 高度相似可作参照。四、风格指南三套规范体系4.1 CCarbon C Project Style GuideC 风格基线是Google C Style Guide其上加一层 Carbon 本地化约束完整内容见 docs/project/cpp_style_guide.md。几个最值得关注的点命名规则已知编译期常量、类型、函数、模板参数、constexpr变量、枚举值等使用UpperCamelCase仅做返回数据成员引用/赋值的成员函数含set_前缀方法可使用snake_case其余名字参数、非 const 局部与成员变量一律snake_case私有成员变量带尾随_。缩写词遵循 Google 的大小写习惯如Api而非API唯二例外是LLVM与IR文件命名一律snake_case同时避免-源文件用.cpp语法细节函数一律使用尾置返回类型包括- void为与 Carbon 语法保持一致指针*紧贴类型名TypeName* variable_nameconst放类型前const int N 42;用using而非typedef不使用using std::vector;这类非限定查找std::显式限定可带来更清晰的诊断并规避 ADL 歧义std::swap这类故意走 ADL 的除外构造函数默认explicit条件/循环语句一律加花括号内部链接优先用static而非匿名命名空间匿名命名空间保留给类与枚举测试代码是例外行注释只允许//且独占一行禁止行尾追加注释dont comment here 反例允许的例外是}的 closing namespace 注释与参数名注释初始化直接赋值用聚合初始化struct/pair/init-list优先花括号并尽量用 designated initializers{.a 1}带构造函数类型用圆括号FooType foo(10);auto花括号初始化被禁止auto a {0, 1}不行地址传递传对象地址时优先引用参数可选或需要超过调用表达式生命周期时用指针并注释空值约定auto使用局部变量普遍使用auto但bool/int等原始类型与较短的具名类型如SemIR::InstId可以显式写出数据结构的选型工具链内优先 LLVM 库与数据结构针对无异常、编译器场景深度优化过不引入第三方库依赖迭代优先明确选择迭代而非递归算法clang-tidy 辅助强制因为编译器要面对代码生成器等对调用栈压力极大的场景迭代在性能与健壮性上更优格式化落地文末指向仓库根目录的 .clang-format 文件即建议的.clang-format内容就是仓库实际使用的配置。4.2 MarkdownGoogle developer documentation style guideMarkdown 风格遵循 Google developer documentation style guide。从 CONTRIBUTING.md 可以补充几个 Carbon 特有的本地化约定用双连字符加空格text -- text替代 em dash因为项目经常在等宽字体下阅读 Markdownem dash 不清晰提到编写 Carbon 代码的人时统一用 developers 一词以覆盖软件开发者、系统工程师、数据科学家等各种自我定位。在工具层面.pre-commit-config.yaml 中的rumdlMarkdown 规范检查--fix与check-google-doc-style钩子负责自动执行。注意check-google-doc-style显式排除了.agents/目录与AGENTS.md即本文所讲的技能卡文档本身不参与该项检查。4.3 PythonPEP 8 与 80 列Python 风格遵循 PEP 8SKILL.md 额外强调两条硬性要求代码与注释折行到 80 列用pre-commit run flake8 --files file.py检查 Python 风格。从仓库现状看Python 生态已演进为 ruff 主导pyproject.toml与.pre-commit-config.yaml中的ruff-check/ruff-format承担了 flake8 的角色ty承担类型检查。仓库中的 Python 脚本如 scripts/run_buildifier.py、scripts/run_bazelisk.py 等均带完整 docstring 与类型注解可视为 80 列与 PEP 8 风格的活样例。五、实操建议把规范嵌入日常工作流结合技能卡与仓库实际推荐贡献者按如下顺序使用这些命令提交前pre-commit install安装 git 钩子后pre-commit run --files 本次改动的文件列表针对变更文件执行全部相关钩子需要单独修某类格式时使用 SKILL.md 给出的pre-commit run hook --files file精确触发Bazel 文件pre-commit run buildifier --files file.bzl实际执行 scripts/run_buildifier.py含 lint 修复C 文件pre-commit run clang-format --files file.cpp随后让check-header-guards校验头文件保护符Markdown 文件pre-commit run prettier --files file.md并留意rumdl与 Google 文档风格检查Python 文件pre-commit run black --files file.py或直接使用配置中的 ruff保持 80 列折行Carbon 文件先运行bazelisk run //toolchain -- format file.carbon验证当前format命令的实际表现若不可用则参照 core/prelude/ 与 examples/ 中的既有代码风格手工排版。全仓级别的完整自检可执行pre-commit run -a但考虑到toolchain/下海量测试语料与pre-commit autoupdate --freeze的版本冻结流程日常开发仍建议以--files定向运行为主。六、小结Carbon 的代码风格体系可以概括为单一来源、工具强制、语言自洽License 合规由check-copyright统一把关格式化统一收敛到 pre-commit 钩子buildifier、clang-format、prettier、black/ruff风格规范则由 C 风格指南这一主文档统摄并通过.clang-format落地执行。值得注意的是Carbon 的 C 风格有意向 Carbon 语言自身的拟议命名规范靠拢——从尾置返回类型到 designated initializers、从UpperCamelCase到snake_case都体现了用 C 代码预演 Carbon 习惯的 dogfooding 思路。对任何参与 Carbon 开发无论人类还是 AI 助手的贡献者而言掌握.agents/skills/code_style/SKILL.md中这套命令与规范是保证提交质量、降低评审摩擦的第一步而仓库根目录的 AGENTS.md 与 CONTRIBUTING.md 则提供了更完整的项目上下文与贡献流程。【免费下载链接】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），仅供参考