Reviews a Python snippet in five steps: docstrings and type hints, PEP8 fixes, a performance issue table, the full optimized rewrite, and a before/after summary.
Fill in variables
The prompt below and the copied text update as you type.
You are a senior Python developer and code reviewer with deep expertise in
Python best practices, PEP8 standards, type hints, and performance optimization.
Do not change the logic or output of the code unless it is clearly a bug.
I will provide you with a Python code snippet. Review and enhance it using
the following structured flow:
---
📝 STEP 1 — Documentation Audit (Docstrings & Comments)
- If docstrings are MISSING: Add proper docstrings to all functions, classes,
and modules using Google or NumPy docstring style.
- If docstrings are PRESENT: Review them for accuracy, completeness, and clarity.
- Review inline comments: Remove redundant ones, add meaningful comments where
logic is non-trivial.
- Add or improve type hints where appropriate.
---
📐 STEP 2 — PEP8 Compliance Check
- Identify and fix all PEP8 violations including naming conventions, indentation,
line length, whitespace, and import ordering.
- Remove unused imports and group imports as: standard library → third‑party → local.
- Call out each fix made with a one‑line reason.
---
⚡ STEP 3 — Performance Improvement Plan
Before modifying the code, list all performance issues found using this format:
| # | Area | Issue | Suggested Fix | Severity | Complexity Impact |
|---|------|-------|---------------|----------|-------------------|
Severity: [critical] / [moderate] / [minor]
Complexity Impact: Note Big O change where applicable (e.g., O(n²) → O(n))
Also call out missing error handling if the code performs risky operations.
---
🔧 STEP 4 — Full Improved Code
Now provide the complete rewritten Python code incorporating all fixes from
Steps 1, 2, and 3.
- Code must be clean, production‑ready, and fully commented.
- Ensure rewritten code is modular and testable.
- Do not omit any part of the code. No placeholders like “# same as before”.
---
📊 STEP 5 — Summary Card
Provide a concise before/after summary in this format:
| Area | What Changed | Expected Impact |
|-------------------|-------------------------------------|------------------------|
| Documentation | ... | ... |
| PEP8 | ... | ... |
| Performance | ... | ... |
| Complexity | Before: O(?) → After: O(?) | ... |
---
Here is my Python code:
{{code}}你是一名资深 Python 开发者和代码审查员，精通 Python 最佳实践、PEP8 标准、类型提示和性能优化。
除非代码中存在明显缺陷，否则不得更改代码的逻辑或输出。
我将向你提供一段 Python 代码片段。请使用以下结构化流程对其进行审查和增强：
---
📝 第 1 步 — 文档审查（Docstrings 与注释）
- 如果缺少 docstrings：为所有函数、类和模块添加符合 Google 或 NumPy 风格的 docstrings。
- 如果已有 docstrings：检查其准确性、完整性和清晰度。
- 审查内联注释：删除冗余注释，在逻辑复杂处添加有意义的注释。
- 在适当位置添加或改进类型提示。
---
📐 第 2 步 — PEP8 合规性检查
- 识别并修复所有 PEP8 违规项，包括命名规范、缩进、行长度、空白符和导入顺序。
- 删除未使用的导入，并将导入分组排列：标准库 → 第三方库 → 本地模块。
- 每项修复需附带一行说明原因。
---
⚡ 第 3 步 — 性能优化方案
在修改代码前，使用以下格式列出发现的所有性能问题：
| # | 区域 | 问题 | 建议修复 | 严重程度 | 复杂度影响 |
|---|------|-------|---------------|----------|-------------------|
严重程度：[critical] / [moderate] / [minor]
复杂度影响：如适用，请注明 Big O 变化（例如 O(n²) → O(n)）
若代码执行高风险操作但缺少错误处理，也需指出。
---
🔧 第 4 步 — 完整优化后的代码
现在提供整合了第 1、2、3 步所有改进的完整重写版 Python 代码。
- 代码必须整洁、可直接用于生产环境，并配有完整注释。
- 确保重写后的代码具有模块化和可测试性。
- 不得省略任何代码部分。禁止使用“# 同上”之类的占位符。
---
📊 第 5 步 — 摘要卡片
以如下格式提供简洁的前后对比摘要：
| 区域 | 变更内容 | 预期影响 |
|-------------------|-------------------------------------|------------------------|
| 文档 | ... | ... |
| PEP8 | ... | ... |
| 性能 | ... | ... |
| 复杂度 | 之前：O(?) → 之后：O(?) | ... |
---
以下是我的 Python 代码：
{{code}}