camelCase、snake_case、kebab-case：各编程语言命名规范速查表
先说结论。类型和类在几乎所有语言中都用 PascalCase（帕斯卡命名）。变量和函数在 JavaScript、Java、C#、Kotlin 和 Swift 中用 camelCase（驼峰命名），在 Python、Ruby 和 Rust 中则用 snake_case（下划线命名）。常量在大多数语言中用 SCREAMING_SNAKE_CASE，Go、Swift、C# 和 Google 风格的 C++ 是例外。凡是会出现在 URL、CSS 文件或包名里的东西，通常用小写的 kebab-case（短横线命名），而环境变量则是用下划线连接的大写字母。
大体规律就是这样。但代码评审里争论的往往是细节，所以这份速查表只讲各语言的官方风格指南（或使用最广的风格指南）实际上是怎么规定的，并为每种语言注明出处。
camelCase、snake_case、kebab-case：五种风格及其别名
- camelCase（
orderTotal）：第一个单词小写，后面每个单词首字母大写。也叫 lowerCamelCase；PEP 8 称之为 mixedCase。 - PascalCase（
OrderTotal）：每个单词首字母都大写。也叫 UpperCamelCase、CapWords（PEP 8）或 StudlyCaps（PHP 的 PSR-1）。 - snake_case（
order_total）：小写单词，用下划线连接。 - SCREAMING_SNAKE_CASE（
ORDER_TOTAL）：大写单词，用下划线连接。Google 的 JavaScript 指南称之为 CONSTANT_CASE，Java 指南则称之为 UPPER_SNAKE_CASE。 - kebab-case（
order-total）：小写单词，用连字符连接。大多数语言不能把它用作标识符，因为连字符就是减号。
要在不同风格之间转换一个名称，把它粘贴到我们的大小写转换器中即可。它会在空格、下划线、连字符和已有的大写字母处拆分单词，所以 order_total、order-total 和 OrderTotal 都能干净利落地互相转换。不过请一次只转换一个名称：它会把框中的全部内容当作一个标识符。
速查表：各语言的命名规范
| 语言 | 变量和函数 | 类和类型 | 常量 | 出处 |
|---|---|---|---|---|
| JavaScript、TypeScript | camelCase | PascalCase | 永不改变的模块级值用 CONSTANT_CASE | Google 的 JavaScript 和 TypeScript 风格指南 |
| Java | camelCase | PascalCase | 深度不可变的 static final 字段用 UPPER_SNAKE_CASE | Google Java Style Guide |
| Kotlin | camelCase | PascalCase | const 以及深度不可变的顶层值或 object 值用 SCREAMING_SNAKE_CASE | Kotlin 编码规范 |
| C# | 局部变量和参数用 camelCase，私有字段用 _camelCase，方法和公共成员用 PascalCase | PascalCase，接口加 I 前缀（IWorkerQueue） | PascalCase | Microsoft .NET 文档 |
| Swift | camelCase | PascalCase | camelCase | Swift API Design Guidelines |
| Go | 不导出时用 camelCase，导出时用 PascalCase | 同一规则 | 同样用 MixedCaps（MaxPacketSize） | Effective Go、Google Go Style |
| Python | snake_case | PascalCase（CapWords） | UPPER_SNAKE_CASE | PEP 8 |
| Ruby | snake_case | PascalCase | SCREAMING_SNAKE_CASE | Ruby Style Guide |
| Rust | snake_case | PascalCase（UpperCamelCase） | SCREAMING_SNAKE_CASE | Rust API Guidelines（RFC 430） |
| PHP | 方法用 camelCase；属性由你自己决定 | PascalCase（StudlyCaps） | 类常量用 UPPER_SNAKE_CASE | PSR-1 |
| C++ | 变量用 snake_case，函数用 PascalCase | PascalCase | kDaysInAWeek | Google C++ Style Guide（多种规范之一） |
有几行需要加个注脚。在 Go 中，首字母根本不是风格选择，而是可见性规则：Area 会从所在的包中导出，area 则不会，这由编译器强制执行。C++ 没有全语言统一的规范；标准库本身用的是 snake_case（std::unordered_map、push_back），所以请把 Google 那一行看作一个有完善文档的选项，而不是唯一的规则。
Rust 对风格的要求格外严格。编译器默认就会发出警告：如果你写 fn GetUser() 或 struct user_account，还没运行 linter，rustc 就会建议你改成 get_user 和 UserAccount。
文件名、模块名和包名
- Java：公共顶层类必须放在与类名完全相同（包括大小写）的文件中。
OrderService要放在OrderService.java里，换成别的名称都会被 javac 拒绝。 - Kotlin：只包含一个类的文件以该类命名。其他文件使用描述性的 UpperCamelCase 名称，例如
ProcessDeclarations.kt。 - Python：模块名应简短、全部小写，如果有助于可读性，可以使用下划线。包名也应简短、小写，PEP 8 不鼓励在包名中使用下划线。
- Ruby：文件名用 snake_case，以其中的类命名，所以
HelloWorld放在hello_world.rb中。 - Go：包名是小写的单个单词，不用下划线，也不用 mixedCaps：写
base64，而不是encoding_base64或encodingBase64。 - JavaScript 和 TypeScript：没有统一的规则。Google 的 JavaScript 指南要求文件名全部小写，可以带下划线或短横线；它的 TypeScript 指南则用 snake_case。Airbnb 的指南规定文件名应与默认导出一致，所以
CheckBox类放在CheckBox.js中。每个项目选定一种，并把它写下来。 - npm 包：新的包名完全不能包含大写字母。
源代码之外：环境变量、CSS、HTML、URL、JSON 和 SQL
| 位置 | 规范 | 示例 | 原因 |
|---|---|---|---|
| 环境变量 | SCREAMING_SNAKE_CASE | DATABASE_URL | 与 PATH、HOME 等系统变量保持一致。在 Linux 和 macOS 上名称区分大小写，在 Windows 上不区分。 |
| CSS 属性 | kebab-case | background-color | 由语言本身规定。 |
| CSS 自定义属性 | 两个短横线后接 kebab-case | --brand-color | 区分大小写，所以 --Brand-Color 会是另一个属性。 |
| CSS 类名 | kebab-case，常与 BEM 搭配 | card__title--large | 与周围的属性读起来风格一致。 |
| JavaScript 中的 CSS | camelCase | el.style.backgroundColor | style 对象以 camelCase 形式提供属性名。 |
| HTML data 属性 | kebab-case | data-index-number | 在 JavaScript 中读作 dataset.indexNumber。 |
| URL 路径 | 小写 kebab-case | /blog/developer-case-styles | Google 建议用连字符而不是下划线，并把 /APPLE 和 /apple 视为不同的 URL。 |
| JSON 键 | 没有标准 | userId 或 user_id | 与主要使用方保持一致，在边界处转换。 |
| SQL 表和列 | 小写 snake_case | order_items | 在所有主流数据库中都无需加引号即可使用。 |
环境变量有个小怪癖：POSIX 规定标准工具使用大写名称，并把含有小写字母的名称留给应用程序使用，所以小写名称永远不会和标准变量冲突。不过大写仍是约定俗成的习惯，所以我们会继续用大写，转而加一个有辨识度的前缀（MYAPP_TIMEOUT）来避免冲突。
CSS 和 SQL 这两行各有专门的文章：类名请看 CSS 命名与 BEM，数据库为什么会把你推向小写，请看 SQL 命名规范。
缩写：风格指南的分歧所在
所有指南在 userName 上意见一致，到了 userID 就各执一词。Google 的 JavaScript 和 Java 指南像对待普通单词一样把缩写转为小写（xmlHttpRequest、customerId）。Go 让每个缩写保持同一种大小写（ServeHTTP、appID）。Microsoft 的 .NET 准则对两个字母的缩写两个字母都大写（IOStream），更长的缩写则只大写首字母（HtmlTag）。Rust 把缩写当作单词处理（Uuid），而 PEP 8 更倾向于 HTTPServerError，而不是 HttpServerError。我们在 camelCase 与 PascalCase 对比一文中把这些做法放在一起做了比较。
拿不准时怎么选
- 先看平台是否已经替你决定了。CSS 属性名、Java 文件名、Go 的导出名称，以及 React 组件名（必须以大写字母开头），都不是风格选择的问题。
- 遵循该语言的官方指南。新代码应该和它所搭配的标准库看起来是一个样子。
- 与现有项目保持一致。PEP 8 说得很直白：项目内部的一致性比与风格指南的一致性更重要。
- 让 linter 替你记住。ESLint 的
camelcase规则、Python 的 RuffN规则以及 rustc 的内置警告，会在评审者开口之前就发现疏漏。 - 只在边界处转换一次。当 snake_case 的 JSON 遇上 camelCase 的 JavaScript 时，在一个序列化层中统一重命名键，而不是让两种风格渗透到整个代码库里。
