为什么要有编码规范
写代码就像写字，如果字迹潦草、格式混乱，别人很难看懂。团队协作开发时，每个人的风格不同，有人喜欢缩进两个空格，有人坚持四个空格；有人在括号前加空格，有人不加。时间一长，项目就像“代码拼贴画”，改个功能都得先花十分钟理解结构。
编码规范就是一套大家共同遵守的“书写规则”，它不决定你能不能实现功能，但决定了别人能不能快速看懂你的逻辑，也决定了你自己半年后再打开这段代码会不会一脸懵。
命名要见名知意
变量和函数的名字不能图省事。比如用 data1、temp、list 这种名字，等于给代码埋雷。换成更具体的名称，比如 userList、calculateMonthlyRevenue，读起来就清楚多了。
类名通常用大驼峰（PascalCase），比如 OrderProcessor；函数和变量用小驼峰（camelCase），比如 getUserInfo；常量全大写加下划线，比如 MAX_RETRY_COUNT。这些细节统一了，扫一眼就知道这是啥。
缩进与空格的一致性
有人喜欢 Tab，有人偏爱空格。其实哪种都行，关键是整个项目保持一致。大多数现代项目倾向于用 2 或 4 个空格代替 Tab，这样在不同编辑器里显示更稳定。
运算符两边加空格，逗号后面加空格，能让表达式更清晰。比如：
if (count > 0 && users.length >= limit) {
console.log('符合条件');
}对比一下没有空格的版本：
if(count>0&&users.length>=limit){
console.log('符合条件');
}是不是第一种更容易分辨出条件逻辑？
注释不是越多越好
好代码应该是自解释的，靠名字和结构就能让人明白意图。过度注释反而干扰阅读，比如下面这种：
// 设置变量为 true
isActive = true;完全没必要。但复杂算法、边界处理或临时 workaround 就需要注释说明原因。重点不是写“做了什么”，而是“为什么这么做”。
函数尽量短小单一
一个函数最好只做一件事。超过 50 行就得考虑拆分了。比如处理用户登录的函数，别一股脑把校验、加密、记录日志、发通知全塞进去。拆成 validateInput、hashPassword、logAccess 等小函数，逻辑清晰，测试也方便。
文件与目录结构有章法
前端项目里，组件、工具函数、样式、API 调用分开存放是基本操作。后端也一样，controller、service、model 各归其位。别把所有文件扔在根目录，找起来像翻垃圾堆。
比如一个电商模块，应该有独立的 /orders 目录，里面再分 controllers、services、validators，结构一目了然。
使用 ESLint 和 Prettier 自动化检查
靠人自觉很难长期坚持规范。ESLint 能帮你揪出潜在错误和风格问题，Prettier 自动格式化代码。配置好之后，保存文件那一刻，缩进、引号、分号自动统一，省心又高效。
团队可以共用一份配置，比如 Airbnb 或 Google 的 JavaScript 风格指南，避免反复争论空格还是 Tab 这种问题。
接口返回格式统一
前后端对接时，接口返回结构最好固定。比如统一用 { code, message, data } 包装响应：
{
"code": 200,
"message": "success",
"data": {
"id": 123,
"name": "张三"
}
}前端处理起来就有套路可循，不用每个接口单独适配。