Python代码规范的目的，是让多人维护的代码更容易理解和修改。风格统一不能保证程序正确，但能减少不必要的阅读和协作成本。与其要求开发人员记住所有细节，不如结合PEP 8、自动化检查和代码评审建立可执行的约定。
PEP 8提供的是风格基线
模块与包名通常采用简短小写形式，必要时可使用下划线；类名一般使用CapWords形式；函数和变量一般采用小写加下划线。历史公共接口及外部协议字段不宜为追求一致性而随意更名。团队可根据项目情况制定例外，并在代码审查中统一遵循。
命名应表达意图
把data、tmp等泛化变量名替换为能准确表达业务含义的名称；但循环局部变量等范围极小的场合无需一味拉长命名。注释更适合解释“为什么这样处理”及约束条件，不能用过时注释重复代码表面逻辑。
格式工具与静态检查分工不同
Black等工具处理代码格式；Ruff等工具可执行多类规则检查并承担部分格式化工作；mypy或其他类型检查工具关注类型一致性。这些工具职责不完全相同，规则之间可能发生冲突，应固定版本和配置并在CI中验证。格式检查通过不等于单元测试通过。
把规则写进代码仓库
团队可以将行长、导入排序、命名约定、排除目录和Python版本统一记录在pyproject.toml等配置中，并在提交前或CI运行。先让新代码满足规则，再评估是否分批清理旧代码；不要为了格式而一次性改动大量无关逻辑。
代码评审关注设计而非只看空格
审查还应检查输入边界、错误处理、事务行为、安全性、日志敏感信息、测试可读性和模块职责。形式规范可交给工具，人的精力应集中在业务正确性、可维护性和风险上。
示例边界
def calculate_order_total(prices: list[float]) -> float:
return sum(prices)
示例只展示命名、类型提示和函数边界，不涉及货币精度；金融或订单金额计算应按实际需求使用Decimal或最小货币单位整数，不能直接将浮点示例用作生产财务计算。
