你有没有遇到过这样的情况：接手一个项目，打开源码，满屏的变量名像是拼音缩写大赛，函数嵌套深得像俄罗斯套娃，缩进错乱得像醉汉走路？那一刻，真想给前任开发者发个消息：咱能有点规矩吗？
代码规范，其实是种“社交礼仪”
写代码不只是和机器对话，更多时候是在和人沟通。哪怕是你一个人写的项目，三个月后的你，也已经是“另一个人”了。代码规范就像程序员之间的暗号，大家约定好怎么命名、怎么排版、怎么组织结构，读起来就顺，改起来就快。
比如变量命名，别用 a、temp、data1 这种名字。换成 userList、isLoading、errorMessage，别人一眼就知道你在干啥，自己回头翻也省心。
缩进和空格，细节见真章
有人爱用四个空格，有人坚持两个，还有人非要用 Tab。其实哪种都行，关键是统一。团队里定好一种，所有人跟着来。别让一段代码里空格和 Tab 交错出现，那感觉就像走在坑洼路上，每一步都硌脚。
举个例子，下面这段 JavaScript，看着就舒服：
function calculateDiscount(price, isMember) {
if (isMember && price > 100) {
return price * 0.8;
}
return price;
}该换行换行，该缩进缩进，逻辑清晰，一目了然。要是全挤在一行，或者大括号位置乱放，读起来就得边解密边理解，效率直接打对折。
注释不是越多越好
很多人以为规范就是多写注释，其实不然。好的代码，本身就应该“自解释”。比如函数名 validateEmailFormat 就比 check 清楚得多，这时候再写个注释“检查输入”，纯属多余。
真正需要注释的是那些“为什么这么做”的地方。比如某个算法用了奇怪的优化，是因为历史兼容问题，这时候加一句说明，后人就不会轻易删掉它，然后发现线上炸了。
工具帮你守住底线
靠人自觉很难持久，最好上点工具。ESLint、Prettier、StyleCop 这些工具，可以在你保存文件时自动格式化、报错提醒。团队一起配置一套规则，提交代码前自动跑一遍，谁也别想“带病上线”。
刚开始可能觉得烦，动不动就被提示“空格不对”“命名不合规”。但时间一长就会发现，这种“强迫症”反而让你写得更轻松——不用边写边想格式，专注在逻辑上就行。
规范不是一成不变的
每个团队、每个项目都有自己的节奏。小项目可以简单点，大项目就得严谨些。关键是达成共识，并且落实下去。别开完会就扔一边，那样只会让规范变成文档里的摆设。
你可以从最痛的地方开始改。比如大家都吐槽日志格式乱，那就先统一日志输出；接口返回结构五花八门，就先定个数据标准。一点点来，比一口吃成胖子靠谱。