elixir-code-review

Elixir 代码审查

快速参考

问题类型	参考资料
命名、格式、模块结构	references/code-style.md
With 子句、守卫、解构	references/pattern-matching.md
GenServer、Supervisor、Application	references/otp-basics.md
@moduledoc、@doc、@spec、doctest	references/documentation.md

审查清单

代码风格

• 模块名采用 CamelCase，函数名采用 snake_case
• 管道链以原始数据开头，而不是函数调用
• 私有函数放在公开函数之后
• 不带参数的函数调用中没有不必要的括号

模式匹配

• 适用时，函数使用模式匹配而不是条件判断
• With 子句对错误情况有 else 处理
• 尽可能使用守卫，而不是运行时检查
• 在函数头中使用解构，而不是在函数体中

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
• 使用 :erlang.binary_to_term/1 时提供 :safe 选项

有效模式（不要标记）

• 用于模式匹配的空函数子句——def foo(nil), do: nil 是有效的保护措施
• 只进行一次转换时使用 |>——这是可读性选择，并非错误
• 在回调实现上使用 @doc false——回调在行为层级记录文档
• 私有函数没有 @spec——内部函数的 @spec 可选
• 使用 Kernel.apply/3——已知模块和函数时，用于动态分派是有效的

上下文相关规则

问题	仅在以下情况下标记
缺少 @spec	函数是公开的且已导出
通用 rescue	存在具体的异常类型
嵌套 case/cond	嵌套超过 2 层

何时加载参考资料

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

报告前的关卡

对本批审查按顺序完成以下步骤。每一步通过前，不要发布审查发现。

1. 已加载协议——阅读 review-verification-protocol，并针对使用的每种发现类别（未使用、验证、安全性、性能等）应用其中的检查。通过条件： 对于每项实质性发现，你都能指出符合的协议小节，或者说明其为 N/A 并给出理由（纯风格问题）。
2. 证据有明确定位——通过条件： 每项发现都包含具体定位：path:line（或行范围），或者 Module.function/arity 加上文件中的简短引用片段。
3. 主张有材料佐证——对于未使用代码、缺少验证或安全风险等断言，通过条件： 附上支持材料（例如搜索结果、文件读取范围），或者将该项降级为明确的问题/不确定，并说明尚未验证的内容。

提交发现前

先完成报告前的关卡（上文部分）；验证协议是这些关卡的必需输入。