代码的命名规范有哪些？
1、命名规范的作用：
让代码更易读、易维护。
2、常用的命名风格：
| 命名法 | 中文名 | 示例 | 说明 |
|---|---|---|---|
| camelCase | 小驼峰 | userName | 首字母小写，后续单词首字母大写 |
| PascalCase | 大驼峰 | UserName | 每个单词首字母都大写 |
| snake_case | 蛇形（下划线式） | user_name | 单词间用下划线分隔 |
| kebab-case | 串式（烤肉式） | user-name | 单词间用连字符分隔 |
| SCREAMING_SNAKE_CASE | 常量式 | USER_NAME | 全大写 + 下划线 |
| Train-Case | 火车式 | UserName（带连字符 User-Name） | 类似帕斯卡但用连字符分隔 |
代码示例
java
// 小驼峰命名示例（camelCase，常用于变量、函数、参数等）
let userName = '张三';
let orderCount = 5;
function getUserDetail(userId) {
return `获取ID为${userId}的用户详情`;
}
// 大驼峰命名示例（PascalCase，常用于类名、组件名、构造函数等）
class UserOrder {
constructor(orderId) {
this.orderId = orderId;
}
}
function OrderComponent() {
return `这是订单组件`;
}3、通用命名原则
（1）见名知意：getUserById 优于 getU。
（2）避免缩写歧义：temp 可以，但 usrTbl 不推荐（除非团队约定）。
（3）长度适中：作用域越小可以越短，全局变量要足够描述性。
（4）避免保留字和单字母：循环变量 i/j/k 可接受，其他场景避免。
（5）一致性优先：团队统一 > 个人偏好。
（6）布尔命名用肯定式：isEnabled 而不是 isDisabled。
（7）避免数字后缀：user1、user2 通常说明设计有问题。
4、命名不规范的后果
（1）看不懂 ------ 自己过段时间也忘了 a、tmp 是啥意思。
（2）容易改错 ------ 名字和实际含义不符，别人误用、误改，产生 bug。
（3）沟通费劲 ------ 评审、交接时要反复解释，效率低。
（4）工具失灵 ------ 框架、IDE、Lint 靠命名约定工作，命名不对就失效。
（5）越维护越乱 ------ 不敢改只能加，代码越来越臃肿，新人上手慢。