为什么需要编码规范
写代码就像写字，如果字迹潦草、格式混乱，别人很难看懂。团队开发中，每个人的编程习惯不同，有人喜欢把括号换行，有人喜欢缩进两个空格，还有人变量名起得像“a1”、“temp2”。时间一长，项目就像一团乱麻，改个功能都得小心翼翼。
编码规范就是一套大家共同遵守的“书写规则”，它不改变程序逻辑，却能让代码看起来整齐划一，提升可读性和协作效率。
常见的通用规范要点
无论用哪种语言，一些基础规则是通用的。比如变量命名要有意义，避免使用单字母（除循环计数外）。i 用在 for 循环没问题，但表示用户ID就该叫 userId。
缩进统一也很关键。现在主流是用 4 个空格或 2 个空格，不要混用 Tab 和空格。编辑器设置好自动转换，能省去不少麻烦。
JavaScript 中的 ESLint 推荐配置
前端项目常用 ESLint 来检查代码风格。一个基础的 .eslintrc.json 配置可以这样写：
{
"env": {
"browser": true,
"es2021": true
},
"extends": [
"eslint:recommended"
],
"parserOptions": {
"ecmaVersion": 12
},
"rules": {
"indent": ["error", 2],
"quotes": ["error", "single"],
"semi": ["error", "always"]
}
}这个配置要求使用 2 空格缩进、单引号、语句结尾加分号。团队成员只要装上插件，保存时就能自动提示问题。
Python 的 PEP 8 标准实践
Python 官方有一份 PEP 8 规范，建议函数和变量用小写下划线，比如 get_user_info，类名用大驼峰 UserDataProcessor。行长度不超过 79 字符，过长要换行。
实际开发中可以用工具 flake8 或 black 自动格式化。比如这段代码：
def calculate_total_price(items, discount=0):
total = sum(item.price for item in items)
return total * (1 - discount)符合 PEP 8，命名清晰，逻辑一目了然。要是写成 calcTotal(items,d=0)，后期维护的人可能得猜半天。
团队如何落地编码规范
光有文档不够，得靠工具约束。可以把 Lint 工具集成到 Git 提交流程中，比如用 Husky 搭配 lint-staged，在代码提交前自动检查。不符合规范的代码直接被拦截，逼着开发者改好再提交。
新成员入职时，给一份简洁的规范文档加几个例子，比口头说“你看着办”强得多。规范不是为了限制自由，而是减少沟通成本，让大家把精力集中在解决问题上，而不是争论括号该不该另起一行。