使用有意义的命名

变量 / 函数名清晰表达用途，避免模糊命名，遵循内部统一的命名规范文档。

避免魔法值

将重复出现的数值 / 字符串定义为常量（如 MAX_RETRY = 3），或用枚举表示状态（如 Status.SUCCESS）。常量的定义来源一致，且语义明确。

尽早返回结果

在函数或方法中，当满足某些特定条件时，提前返回return结果，而不是继续执行后续的代码。

减少全局变量使用

不同模块或函数可能使用相同的全局变量名，从而引发命名冲突。

全局变量的作用域覆盖整个程序，维护和调试困难。

多线程或多进程的环境中，容易引发数据竞争和不一致的问题。

合理使用注释

对代码进行修改或扩展时，注释可以提供重要的上下文信息，减少误解和错误。

注释可以帮助其他开发者（也包括自己）快速理解复杂业务代码。

注释格式统一，同时避免注释过度（没啥意义）。

检查输入

对外部输入（用户参数、API 返回）做严格校验，避免空指针 / 越界等问题。例如：数据范围、类型、长度、格式等。

优先使用内置工具类或函数

自带的工具类和函数是经过优化的。但是需要避免过度依赖，存在跨平台或者跨版本兼容性等。

重复计算结果进行缓存

将已经计算过的结果存储起来，当再次需要相同的计算结果时直接从缓存中获取，不必重新进行计算。避免了重复计算所带来的时间和资源消耗。

但是，需注意：缓存一致性、缓存过期策略、缓存容量管理、并发访问问题。

关注循环业务性能

不当的循环使用可能会导致性能问题，影响程序的运行效率。

减少循环次数，提前终止循环，避免不必要的循环嵌套。

减少函数调用， I/O 操作，在循环查询频繁查询数据库中。

警惕隐式类型转换

隐式转换容易导致数据丢失、逻辑错误，同时高频隐式类型转换可能增加程序运行时间和内存开销。

在弱类型语言（如 JavaScript）中，用 === 替代 == 避免类型自动转换导致的逻辑错误（如 0 == false 为真，0 === false 为假）。

小数点

涉及财务相关的应用时，小数点的处理至关重要。常见的情况有：精度丢失、四舍五入误差、显示格式问题。

使用高精度数据类型，明确舍入规则（四舍五入、向上取整、向下取整、见分进角）

小步提交，描述清晰

小步提交能快速定位到问题具体提交版本，代码改动量小，审查人员可以更快速地理解代码变更意图和影响。同时便于版本回滚方便。

避免过度拆分，遵循团队规范。

关注维护性，合理性而非代码风格

代码审查重点检查逻辑漏洞、边界条件、复杂度（如圈复杂度），而非纠结空格或括号风格，有点吹毛求疵了。

避免过度设计带来反面影响

过度设计的表现：过度使用设计模式，过度追求扩展性，添加不必要的功能。

过度设计的坏处：增加开发成本，降低开发效率，影响系统性能，增加维护难度。

简单场景优先用基础逻辑，复杂场景再引入模式。

日志记录不可少

日志重要性：问题排查与调试，系统监控与性能分析，合规性与审计，日志中记录的用户行为数据等。

日志级别合理设置，内容要有意义，最好采用异步记录，存储和管理要重视，安全也要过关。

二分法定位问题

遇到复杂 bug 时，通过注释代码、分块测试，快速缩小问题范围（如 最近一次提交引入的问题？某个模块导致的？）。

数据查询尽量命中索引

为经常用于查询条件、排序和连接的列创建索引，可显著提高查询速度。

异步任务

在处理 I/O 密集型任务时，使用异步编程可以提高程序的并发性能。防止系统阻塞，导致大量资源消耗。

及时释放资源

资源未及时释放的可能导致应用系统性能下降甚至系统崩溃，数据丢失或损坏等。

在使用完文件、网络连接、数据库连接等资源后，要及时关闭和释放。

封装函数或者工具

将重复使用的代码逻辑封装成函数，提高代码的复用性。

代码风格一致性

使用代码风格检查工具来确保代码符合团队的约定风格。