命名格式与命名约定详解
代码、文件、URL 和标题中的名称遵循的约定，因语言和格式而异。本指南列出常见的命名格式、各自适用的场合，以及容易出错的细节：缩写、数字、标题和英语以外的字母。
常见的格式
| 格式 | 示例 | 构成方式 |
|---|---|---|
| camelCase | orderTotal | 第一个单词小写，后面每个单词首字母大写，无分隔符 |
| PascalCase | OrderTotal | 每个单词首字母大写，无分隔符 |
| snake_case | order_total | 小写，单词用 _ 连接 |
| CONSTANT_CASE | ORDER_TOTAL | 大写，单词用 _ 连接 |
| kebab-case | order-total | 小写，单词用 - 连接 |
| dot.case | order.total | 小写，单词用 . 连接 |
| Title Case | Order Total | 单词用空格分开，每个单词首字母大写 |
| Sentence case | Order total | 只有第一个单词首字母大写 |
camelCase 有时称为小驼峰，PascalCase 称为大驼峰。CONSTANT_CASE 也叫 screaming snake case。
各种语言和格式期望的格式
大多数生态早已形成约定，遵循它能让熟悉该生态的人都更容易读懂代码：
| 场合 | 通常的约定 |
|---|---|
| JavaScript、TypeScript、Java | 变量和函数用 camelCase，类用 PascalCase，固定常量用 CONSTANT_CASE |
| Python（PEP 8） | 函数和变量用 snake_case，类用 PascalCase，常量用 CONSTANT_CASE |
| C# | 类型、方法和公共成员用 PascalCase，局部变量和参数用 camelCase |
| Go | PascalCase 让名称在包外可见，camelCase 让它保持私有 |
| Ruby、Rust | 方法和变量用 snake_case，类型用 PascalCase |
| CSS 和 HTML | 属性、类名和 data- 属性用 kebab-case |
| URL | kebab-case；Google 建议单词之间用连字符而不是下划线 |
| SQL 表和列 | snake_case，因为许多数据库会把不加引号的名称统一成一种大小写 |
| 环境变量 | CONSTANT_CASE，例如 DATABASE_URL |
| 配置键 | 嵌套设置用 dot.case，例如 server.port |
| JSON API | 没有统一规则：很多用 camelCase，也有用 snake_case 的；遵循你所使用的 API |
在大多数编程语言中，变量名不能使用 kebab-case，因为连字符会被当作减号：order-total 的意思是 order 减去 total。
缩写和数字
各种约定分歧最大的地方是缩写。一派保持大写（userID、parseHTML），另一派把它们当作普通单词（userId、parseHtml）。Google 的 Java 和 JavaScript 风格指南采用后者，这样缩写相连时单词边界依然清晰：XmlHttpRequest 比 XMLHTTPRequest 更容易拆分。Microsoft 的 .NET 规范让两个字母的缩写保持大写（IOStream），更长的缩写只大写首字母（HtmlButton）。浏览器 API XMLHttpRequest 两种写法混用，因此常被当作反例引用。
数字没有大小写，所以转换器无法判断 utf8Decoder 的意思是“utf8 decoder”还是“utf 8 decoder”。转换器通常把数字附在前一个单词上。选定一种写法，并在所有地方统一使用。
标题中的 Title Case 与 Sentence case
在英文标题中，各种风格指南对大写的处理并不相同。AP 和 Chicago 风格会把短的冠词、连词和介词保持小写，除非它们位于开头或结尾（"The Lord of the Rings"），而且两者的具体清单不同。许多界面和文档指南，包括 Microsoft 和 Google 的开发者文档指南，改用 Sentence case（"Change your password"），这样更容易统一执行，读起来也不那么正式。
LeedyBox 转换器的 Title Case 会把每个单词的首字母大写，这适合标签和类似变量的名称，但不适合报纸式标题：转换后请手动把短词改回小写。
格式转换会丢失信息
每次转换都会先以大写字母和分隔符为线索把名称拆成单词，再用新格式把单词连起来。目标格式无法表达的内容就会丢失：parseHTML 变成 parse_html，再转回来就成了 parseHtml。标点也会被去掉，所以 "don't" 会变成两个单词。
因此，应以一种格式作为唯一来源。如果数据库用 snake_case、代码用 camelCase，就在边界处每次按同一方向转换，而不要把名称以两种形式都保存下来。
跨 API 边界重命名键
当使用 camelCase 的前端与使用 snake_case 的后端通信时，大多数序列化库都能自动映射名称，因此不必手动重命名数据。一次性转换一份 JSON 文档（例如测试数据或示例响应）则是另一回事，命名格式转换工具的“JSON 键”模式可以在不改动值的情况下完成。
注意冲突：user_name 和 userName 无论转成哪种格式都会变成同一个键，其中一个会覆盖另一个。以符号开头的键，如 _id 或 $ref，往往对特定的数据库或模式有意义，请先确认它们是否可以改名。
英语以外的大小写
大小写规则并非在每种语言中都相同。德语的 ß 转成大写时会变成 SS，单词因此变长。土耳其语有带点的 i 和不带点的 ı：其大写对应关系是 i → İ、ı → I，而大多数编程语言使用的默认规则会把 i 变成 I。JavaScript 的 toUpperCase() 使用默认规则；toLocaleUpperCase('tr') 则使用土耳其语规则。韩语、中文和日语根本没有大小写，因此只有单词之间的分隔符会改变。
文件名的大小写也可能造成影响。Windows 和默认设置下的 macOS 会把 Readme.md 和 README.md 视为同一个文件，而 Linux 视为两个文件。因此，只改变大小写的重命名，可能在一个系统上毫无察觉，却在另一个系统上导致链接或 import 失效。
常见问题
camelCase 和 snake_case 哪个更好？
一般来说没有哪个更好。请遵循你正在使用的语言、框架或 API 的约定；在同一个代码库中保持一致，比选择本身更重要。
URL 应该用连字符还是下划线？
用连字符。Google 关于 URL 的指南建议在单词之间使用连字符，像 /case-converter/ 这样的 kebab-case 路径在网络上很常见。
为什么只改了文件名的大小写，Git 却没有察觉？
在不区分大小写的文件系统上，Git 常把新旧名称当作同一个文件。请用 git mv 重命名，例如先改成一个临时名称，这样区分大小写的系统也能记录这次更改。
像 iPhone 或 eBay 这样的品牌名，用 camelCase 应该怎么写？
转换器会在大写字母处拆分单词，所以这类名称会变成独立的单词。在代码中，通常把品牌当作一个单词更清楚（iphoneModel），官方写法只用在给人看的文本中。