先思考：为什么代码要有命名规范？
首先代码是写给人看的，然后才给机器执行。其次团队协作间统一语言可以减少沟通成本。同时最重要的是，规范命名便于长期维护代码。核心目的就是让别人（以及未来的你）在最短时间内看懂代码。
1.大驼峰 PascalCase（帕斯卡命名法）
规则：每个单词首字母大写，无分隔符
示例：UserInfo、OrderService、StudentScoreList
2.小驼峰 camelCase（驼峰命名法）
规则：第一个单词首字母小写，后续单词首字母大写，无分隔符
示例：userInfo、orderList、getUserById
3. 蛇形命名 snake_case（下划线命名）
规则：全部小写，单词之间用下划线 _ 分隔
示例：user_age`、`order_list
4. 大写蛇形 UPPER_SNAKE_CASE（宏命名）
规则：全部大写，下划线分隔
示例：MAX_PAGE_SIZE、DEFAULT_TIMEOUT
5. 短横线命名 kebab-case（烤串命名）
规则：全部小写，单词用 - 分隔
示例：user-name、page-header
⚠️ 绝大多数编程语言变量名不能用（减号会被识别成运算符） 适用场景：CSS class、URL、文件名、HTML 属性
6. 匈牙利命名法 Hungarian notation
规则：变量名前缀增加类型标识，后面接业务名称
示例：strUserName（str = 字符串）、nCount（n = 数字）
现状：现在不推荐，老 C++/Windows 代码多见，现代 IDE 可以直接看类型，冗余。
主流语言推荐命名规范
| 语言 | 类 / 类型 | 变量 | 函数 / 方法 | 常量 |
|---|---|---|---|---|
| Java | PascalCase | camelCase | camelCase | UPPER_SNAKE_CASE |
| JavaScript/TS | PascalCase | camelCase | camelCase | UPPER_SNAKE_CASE |
| Python | PascalCase（类） | snake_case | snake_case | UPPER_SNAKE_CASE |
| C# | PascalCase | camelCase（局部变量） | PascalCase（方法） | UPPER_SNAKE_CASE |
| Go | PascalCase（导出）/ camelCase（私有） | camelCase | camelCase | UPPER_SNAKE_CASE |
| SQL | snake_case | snake_case | - | UPPER_SNAKE_CASE |
⚠️说明：Go 官方没有 camelCase 叫法，公开标识符大驼峰，私有标识符小驼峰。
通用命名原则（不管哪种风格都要遵守）
- 见名知意，不要单字母无意义命名（除循环
i,j） - 不要拼音混合英文（尽量纯英文）
- 不要缩写滥用，通用缩写可以（id、url、ctx）
- 命名区分名词 / 动词：变量是名词（
user），函数是动词短语（getUser） - 保持项目内风格统一
- 布尔变量优先使用
is/has/can/should前缀；集合、数组变量尽量使用复数形式 - 避免冗余重复词汇，少用泛化无意义单词：
info、data、model - 特殊缩写驼峰处理：缩写仅首字母大写，如
userId、userUrl，禁止写为userID、userURL - 函数动词语义明确；拒绝笼统模糊动词，如
handle、process
❌ 反面错误示例（避坑参考）
- 无意义命名：
a、temp1、dataInfo，无法体现业务含义（循环 i/j 除外） - 中英拼音混合：
userXinXi、dingDanList - 过度缩写：
usrInf、ordSvc - 语义模糊函数：
handleData()，看不出新增、删除、查询逻辑，应改为saveUserData() - 命名冗余：
userInfoModel（类本身就是 Model，无需重复后缀）、orderOrderNo单词重复 - 布尔语义模糊：
flag、status、isOk；- ✅推荐：
isEnabled、hasPermission、canSubmit、shouldRefresh
- ✅推荐：
- 集合单数命名：用
user存储数组集合；✅正确写法userList、orderIds
