Elixir 代码审查

快速参考

审查清单

代码风格

• 模块名使用 CamelCase，函数名使用 snake_case
• 管道链（pipe chain）应以原始数据开头，而非函数调用
• 私有函数置于公有函数之后并分组组织
• 无参函数调用中不使用不必要的括号

模式匹配

• 在适用场景下，优先使用模式匹配而非条件语句
• with 子句需包含 else 分支以处理错误情况
• 在可能情况下，使用守卫（guards）替代运行时检查
• 解构（destructuring）应在函数头中完成，而非函数体内部

OTP 基础

• GenServer 在初始化开销较大时应使用 handle_continue
• Supervisor 应采用合适的重启策略
• GenServer 回调中不得包含阻塞式调用
• 正确区分 call（同步）与 cast（异步）的使用场景

文档

• 所有公有函数均需配备 @doc 和 @spec
• 模块需包含 @moduledoc，说明其用途
• 对纯函数，在适当情况下编写 doctest
• 不得对真正公有的函数标注 @doc false

安全性

• 禁止对用户输入调用 String.to_atom/1（应使用 to_existing_atom/1）
• 禁止对不可信输入调用 Code.eval_string/1
• 禁止在未指定 :safe 选项的情况下调用 :erlang.binary_to_term/1

允许的模式（请勿标记）

• 为空值模式匹配定义空函数子句 —— def foo(nil), do: nil 是合法的守卫用法
• 单次转换时使用 |> —— 属于可读性权衡，不视为错误
• 回调实现中标注 @doc false —— 行为规范（behaviour）层面已统一文档化
• 私有函数未标注 @spec —— @spec 对内部实现为可选
• 使用 Kernel.apply/3 —— 在模块/函数确定的前提下，适用于动态分发场景

上下文敏感规则

何时查阅参考文档

• 审查模块/函数命名 → code-style.md
• 审查 with/case/cond 语句 → pattern-matching.md
• 审查 GenServer/Supervisor 相关代码 → otp-basics.md
• 审查 @doc/@moduledoc → documentation.md

上报前须通过的校验关卡（Gates）

请按以下顺序对本次审查批次执行全部步骤。任一关卡未通过前，不得发布任何发现结果。

1. 协议已加载 —— 阅读 review-verification-protocol，并对其涵盖的每一类发现（如：未使用代码、验证缺失、安全风险、性能问题等）执行对应检查。通过标准：对每一项实质性发现，须明确指出所满足的协议子章节；若不适用，则须注明 N/A 并说明原因（例如：纯属风格问题）。
2. 证据定位明确 —— 通过标准：每项发现均需提供具体定位信息：如 path:line（或行号范围），或 Module.function/arity 加上文件中的简短引用片段。
3. 主张有依据支撑 —— 对于“未使用代码”、“缺失验证”或“安全风险”等断言，通过标准：须附上支撑性工件（例如：搜索结果、文件读取范围等）；若无法提供，则须将该项降级为明确标注的 疑问 或 存疑 条目，并说明未验证的内容。

提交发现前的必要步骤

请首先完成上方 Gates — before reporting 全部步骤；验证协议是执行这些关卡的强制前置输入。