如何按组织需求 fork C Core Guidelines 并定制自己的规范副本【免费下载链接】CppCoreGuidelinesThe C Core Guidelines are a set of tried-and-true guidelines, rules, and best practices about coding in C项目地址: https://gitcode.com/gh_mirrors/cp/CppCoreGuidelines如果你的目标是让团队按照组织自己的编码约定使用 C Core Guidelines而不是原样照搬上游规范官方建议的做法是fork 这个仓库建立一份属于你组织的副本并加入反映你组织需求的修改。本文章按 CONTRIBUTING.md 中Organizational adoption一节说明的操作路径带你完成 fork、定制以及用仓库自带脚本核对副本格式的全过程。授权前提副本可以用于组织内部在开始之前先确认使用权。LICENSE 规定 Standard C Foundation 授予一份全球性的、非独占的、免版税的、永久许可允许复制或修改本项目、创建衍生作品但仅限个人或内部商业使用并要求在所有副本或实质部分中保留版权声明与许可声明。规范正文 CppCoreGuidelines.md 开头也写明复制、使用、修改以及创建衍生作品遵循MIT-style license向该项目贡献内容则需接受 Contributor License 协议详见 CONTRIBUTING.md 中的Contributor License Agreement。对 fork 场景来说关键点是在你的组织内部维护一份修改过的规范副本属于许可范围内。文档同时说明这份指南的设计初衷就是freely copied and modified to meet your organizations needs可自由复制和修改以满足组织需求因此组织定制是被官方鼓励的而不是灰色操作。准备克隆上游仓库并配置 git定制副本的起点是上游仓库的一份本地克隆。仓库根目录包含规范正文 CppCoreGuidelines.md、LICENSE、CONTRIBUTING.md 以及用于格式检查的 scripts/ 目录含 Makefile。克隆之后按 CONTRIBUTING.md Miscellaneous 一节的要求设置 git 配置避免换行符问题git config autocrlf input git config whitespace cr-at-eol定制副本官方给出的三条要求fork 之后CONTRIBUTING.md 明确给出了三条组织定制要求前两条是建议We suggest第三条是如果……请在副本标题中表明身份让规范副本的标题明确写出这是你组织 fork 的 guidelines 版本例如标题里带上组织名。保留指回上游的链接副本中提供一个指向原始 guidelines 的链接说明其来源。本地修改若适用回推上游如果你的某些本地修改也适合并入原始 guidelines就开一个 Issue由此进入 pull request 流程。规范正文是单个 Markdown 文件见下文样式约束定制时直接编辑 CppCoreGuidelines.md 的对应章节即可仓库结构里没有拆分章节文件——这一点在 CONTRIBUTING.md Document style decisions 中被明确列为已定决策该文件是单个 GH-flavored Markdown 文件不拆分成独立章节。定制时必须遵守的样式约束修改副本内容时以下规则决定了你的修改能否通过仓库自带的检查也决定了副本是否与上游风格一致来源CONTRIBUTING.md Document Style Guidelines 与 Document style decisions缩进代码和嵌套文本使用 4 的整数倍空格缩进不使用制表符tab 字符。代码块使用 4 空格缩进触发代码解析而不是 fenced code blocks 围栏或其他风格。单文件结构不拆分章节与上面第 3 条一致。不做语法高亮官方明确不对 Core Guidelines 使用 syntax highlighting需要高亮的人可看pretty版本或自行做后处理。只使用 ASCII 字符集不使用 Unicode em-dash、Unicode 空格、花引号pretty quotes等字符。这些约束不是风格偏好而是与检查脚本逐条对应tab 检查、bad-char 检查、remark markdown 检查都会对违反项报错下一节。结果验证用 scripts/Makefile 检查定制后的副本仓库的 scripts/Makefile 就是验证副本格式的工具。它在本地或 CI 上运行前提是已安装 npmMakefile 头部注释与nodejs/node_modules/%目标均注明依赖 npm 安装 nodejs 依赖即 scripts/nodejs/package.json 中定义的 remark 等包。在scripts/目录下执行makeall目标依次执行六项检查每项失败时打印具体输出并中断检查目标检查内容失败时的提示check-markdown用 remark配置见nodejs/remark/.remarkrc检查 Markdown 语法将建议的修正结果与原文件 diffError: remark found bad markdown syntax, see output abovecheck-references检查a name...锚点是否唯一重复锚点会被列出Found duplicate anchors:check-notabs找出含 tab 字符的行Warning: Tabs found:hunspell-check用 hunspell 加 scripts/hunspell/isocpp.dic 自定义字典做拼写检查Warning: Spellcheck failed, fix words or add to dictionary:cpplint-all用 scripts/python/cpplint.py 检查文档中提取出的 C 代码块见 cpplint 输出check-badchars找出非 ASCII 字符‘ ‘ “ ” ¸ … ¦等及 Unicode EN SPACEWarning: Undesired chars ... use markdown-compatible symbols instead:make全部跑完且无报错就是定制后的副本在格式上与上游规则保持一致的判定标准。两个与定制直接相关的补充说明新增标识符要进字典。CONTRIBUTING.md Update dictionary 一节要求代码示例中的新类和变量名必须加入 scripts/hunspell/isocpp.dic否则hunspell-check会把它们当作拼写错误。只想看某项检查的建议而不报错make show-diff会生成build/CppCoreGuidelines.md.fixed不直接 fail方便你先看 remark 建议了哪些修改。把本地修改回推上游可选如果你的定制中发现某些规则在上游也不合适CONTRIBUTING.md 给出了回推路径欢迎范围明确的小改动示例中的 bug 修复、消除歧义的措辞等可以直接提交 pull request。重大改动先开 Issue 讨论且 pull request 中必须包含 Issue 编号涉及具体 guideline 规则的变更请在 Issue 和/或 PR 中标明规则编号。改动应基于 master 分支近期提交的子提交改动较多时拆成多个 PR 以减少合并冲突。提交内容即视为接受 Contributor License 协议授予 Standard C Foundation 使用、复制、创建衍生作品等的许可详见 CONTRIBUTING.md Contributor License Agreement。限制与边界本仓库是持续演进的文档没有严格的发布节奏版本号由 Bjarne Stroustrup 周期性审查后在引言中递增递增版本的 git 提交会被打 tag见 README.md Getting started。你的副本与上游会自然漂移需要自行决定何时同步上游变更。上游维护的formatted for browsing版本是手工整合的可能比 master 分支略旧README.md。定制时应以仓库内的 CppCoreGuidelines.md 为准。许可仅限内部使用对外分发你的规范副本时LICENSE 中personal or internal business use only的限定需要你先自行确认适用范围。规范中的规则意在渐进式引入代码库README.md Background and scope部分规则可能过严、需要更多例外这些都属于上游已声明的已知状态定制副本时不必强行修好它们。完成上面的流程后你得到的是一个标题标明组织归属、保留上游链接、内容按组织需求修改、且make全部检查通过的规范副本后续上游同步与规则回推都有既定路径可依。【免费下载链接】CppCoreGuidelinesThe C Core Guidelines are a set of tried-and-true guidelines, rules, and best practices about coding in C项目地址: https://gitcode.com/gh_mirrors/cp/CppCoreGuidelines创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考