pythia-review

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Reviewing PL/SQL

审查PL/SQL代码

Announce at start: "Using pythia-review — checking the database's signals first."

Review in two passes: what the database knows is wrong, then what the checklist says is likely wrong. Machine signals first — they are free and exact.

开始时说明：“正在使用pythia-review——首先检查数据库的校验信号。”

审查分为两轮：先检查数据库明确识别的错误，再检查清单中标记的潜在问题。优先参考机器校验信号——这类信号免费且精准。

Pass 1 — the database's own verdict

第一轮：数据库的校验结果

```
pythia errors NAME
```
— compile errors and warnings with line:column. An object that does not compile needs no style review yet.
```
pythia src NAME
```
— read the source with the compiler's line numbers, so findings can be anchored (
```
line 47: ...
```
).
```
pythia impact NAME --depth 2
```
— how exposed is this object; a finding in something with 40 dependents outranks the same finding in a leaf.
For a proposed file (not yet applied): the compile verdict arrives at apply time — say explicitly that compilation is still unverified.

```
pythia errors NAME
```
—— 查看带行号:列号的编译错误与警告。无法编译的对象无需先进行风格审查。
```
pythia src NAME
```
—— 按编译器的行号读取源代码，以便准确定位问题（如
```
第47行：...
```
）。
```
pythia impact NAME --depth 2
```
—— 评估该对象的影响范围；若某问题存在于有40个依赖项的对象中，其优先级高于存在于叶子节点对象中的同类问题。
对于待提交的文件（尚未应用到数据库）：编译结果需在应用时才能确定——需明确说明编译状态尚未验证。

Pass 2 — the antipattern checklist

第二轮：反模式检查清单

Work through

reference/antipatterns.md

— and the project's own

.pythia/conventions.md

when it exists, which outranks the generic list. The seven entries, each with wrong → right → why: row-by-row cursor loops, string-concatenated dynamic SQL,

WHEN OTHERS THEN NULL

COMMIT

inside loops, hand-copied types instead of

%TYPE

%ROWTYPE

, large OUT parameters without

NOCOPY

, and convention drift against the codebase (

pythia similar

shows the house style).

对照

reference/antipatterns.md

进行检查——若项目存在自定义的

.pythia/conventions.md

，则优先遵循该文件而非通用清单。清单包含七项内容，每项均涵盖错误用法→正确用法→原因说明：逐行游标循环、字符串拼接的动态SQL、

WHEN OTHERS THEN NULL

、循环内的

COMMIT

、手动复制类型而非使用

%TYPE

%ROWTYPE

、未使用

NOCOPY

的大型OUT参数，以及与代码库约定不符的风格偏差（

pythia similar

可显示项目的规范风格）。

Reporting findings

审查结果报告

Anchor every finding:

line N: <what> — <why it bites> — <the fix>

Severity order: breaks correctness → silently loses data or errors → performance at scale → style drift.
Verify the claim before writing it: read the actual lines with
```
src
```
; never report from memory of the diff alone.
A clean review says what was checked, not just "looks good": compiles clean, no new INVALID, checklist passed.

所有问题均需标注行号：

第N行：<问题内容> —— <问题影响> —— <修复方案>

。

按严重程度排序：破坏正确性→静默丢失数据或错误→大规模场景下的性能问题→风格偏差。
报告前需验证问题：使用
```
src
```
命令查看实际代码行；切勿仅根据差异记忆进行报告。
无问题的审查需明确说明检查内容，而非仅回复“看起来没问题”：需说明编译通过、无新的INVALID对象、通过清单检查。

When NOT to use this skill

不适用本方法的场景

Reviewing whether a change is safe to apply — that is
```
pythia-impact
```
plus
```
pythia-apply
```
's preview; this skill judges the code itself.
Reviewing non-PL/SQL application code — outside this skill's scope.

审查变更是否可安全应用——此类场景应使用
```
pythia-impact
```
结合
```
pythia-apply
```
的预览功能；本方法仅用于评估代码本身的质量。
审查非PL/SQL的应用代码——超出本方法的适用范围。