为什么需要写代码规范
刚进新公司那会儿，我打开项目代码差点没认出来这是JavaScript。变量命名像谜语，缩进全靠心情，一个文件里四种风格来回切换。后来才知道，这不是个性飞扬，是缺乏规范。
代码规范不是为了束缚手脚，而是为了让多人协作时少点“这谁写的？”的暴躁时刻。它像是厨房里的操作守则——你切菜我炒菜，大家用同一套流程，才能端出一盘不糊的番茄炒蛋。
从实际问题出发定规则
别一上来就照搬大厂模板。先看看你们团队最近踩过哪些坑：
- 有人用
camelCase，有人偏爱snake_case - 缩进用两个空格还是四个，争论得像选阵营
- 函数前面加不加空行，Pull Request 里吵翻天
这些问题就是规范要解决的起点。开会十分钟，把这些争议项列出来，投票决定统一做法，比抄一百条规则都管用。
命名规则要能“读”懂
变量名别玩猜谜游戏。data、temp、info 这类名字就像快递单上写“本人签收”，等于没说。
比如处理用户登录状态，与其叫 flag，不如直接写 isUserLoggedIn。三个月后你再看代码，不用回忆上下文，一眼就知道它干啥。
格式统一靠工具卡住
人总会犯懒。再熟的规则，手速一快也可能走样。这时候就得上工具。
在项目里配个 .prettierrc 文件，团队成员只要装了插件，保存文件自动格式化：
{
"semi": true,
"trailingComma": "es5",
"singleQuote": true,
"printWidth": 80
}再配上 ESLint 检查语法问题，提交代码前跑一遍检查，不合规范的根本提不了。硬性约束比口头提醒靠谱多了。
注释不是越多越好
别在每行代码后面写“这行声明变量”，这种注释跟在路口立牌子写“这里是路”一样多余。
真正该写注释的是那些“反直觉”的地方。比如为什么这里要用 setTimeout 延迟执行，或者某个算法绕了个弯的考量。这些才是后来者需要知道的背景故事。
留点弹性空间
规范不是法律条文，得允许例外。比如某些性能关键路径上的代码，为了效率牺牲一点可读性，可以特批豁免。
关键是要有记录。用 // eslint-disable-next-line 这类标记说明原因，别人看到就知道：“哦，这是故意的，不是手滑。”
代码规范的本质，是帮团队建立共同语言。它不需要完美无缺，但得真实可用。从小处开始，遇到问题就补充一条，慢慢就能攒出一套真正属于你们自己的规则手册。