Python Code Review Checklist Template

Standard Operating Procedure: Python Code Review Checklist Template

1. Document Control & Revision History

---

2. Executive Summary & Scope

2.1 Purpose

This Standard Operating Procedure (SOP) defines the mandatory operational framework, analytical procedures, and verification gates for executing peer code reviews on Python-based enterprise software artifacts. Adherence ensures systemic reduction of technical debt, elimination of critical security vulnerabilities, enforcement of PEP 8 style parity, and maximization of runtime performance.

2.2 Operational Boundaries

This SOP applies unconditionally to all production-bound, staging-bound, and internal core libraries written in Python across all engineering departments. It governs contributions submitted via Pull Requests (PRs) or Merge Requests (MRs) targeting protected upstream branches (main, master, release/*).

2.3 Regulatory and Compliance Standards

Executions under this SOP must maintain compliance with:

• OWASP Top 10 Application Security Risks (specifically injection, broken authentication, and insecure deserialization).
• PEP 8 / PEP 257 / PEP 484 (Style, Docstring, and Type Hinting standards).
• SOC 2 Trust Services Criteria (Security, Availability, and Processing Integrity).
• ISO/IEC 25010 (Software product quality models for maintainability and reliability).

---

3. Prerequisites & Tool Requirements

3.1 Software Access and Tooling

Reviewers and authors must have execution access and active configurations for the following systems within the local development environment and CI/CD pipelines:

• Version Control System: GitHub Enterprise or GitLab Enterprise with branch protection rules enforced.
• Static Analysis & Linting:
  • Ruff (Unified Python linter and code formatter, superseding Flake8, Black, and isort).
  • MyPy (Static type checker, strict mode configured).
  • Bandit (Static security analyzer for common Python security flaws).
• Dependency Management: Poetry or Pipenv with lockfile verification.
• Testing Framework: pytest with pytest-cov (minimum 85% branch coverage).

3.2 Certifications & Training

• Reviewer Qualification: Internal certification as a Tier-2 Code Reviewer or higher, requiring completion of Secure Coding in Python and Enterprise Architecture standards modules.

---

4. Roles & Responsibilities (RACI Matrix Table)

Legend:

• R - Responsible (The role that performs the activity)
• A - Accountable (The sole decision-maker with final approval)
• C - Consulted (The role providing advisory input)
• I - Informed (The role kept updated on progress/status)

---

5. Step-by-Step Operational Procedure

Phase 1: Pre-Review Triage & Automated Gate Verification

• 1.1 Verify that the pull request contains a clear, standardized title and references an active enterprise Jira/Linear ticket.
• 1.2 Confirm that all automated CI pipeline checks (Build, Lint, SAST, Unit Tests) have passed successfully without warnings.
• 1.3 Validate that no merge conflicts exist with the target branch (main/master).
• 1.4 Ensure code coverage reports show no regression below the mandatory 85% threshold.

Phase 2: Architectural & Design Pattern Audit

• 2.1 Verify adherence to SOLID principles, ensuring single-responsibility boundaries for newly introduced modules and classes.
• 2.2 Validate that business logic is decoupled from external I/O boundaries (database, network, file system) via dependency injection or service layers.
• 2.3 Confirm proper management of state; inspect for unintended side-effects in global variables or mutable default arguments (e.g., def func(data: list = []):).
• 2.4 Evaluate concurrency paradigms; ensure that asynchronous code (async/await) does not block the event loop with synchronous I/O or CPU-heavy computations.

Phase 3: Code Correctness & Maintainability Inspection

• 3.1 Inspect explicit type hints on all public function signatures, parameters, and return types according to PEP 484.
• 3.2 Check for clear, unambiguous naming conventions (snake_case for variables/functions, PascalCase for classes, UPPER_SNAKE_CASE for constants).
• 3.3 Validate docstring coverage (Google or Sphinx format) on all public modules, classes, and methods detailing arguments, raises, and return values.
• 3.4 Confirm that exception handling is granular; explicitly forbid bare except: clauses or unhandled generic Exception catches at deep call stacks.

Phase 4: Security, Performance, & Data Integrity Review

• 4.1 Audit all database interactions for parametrization; verify complete absence of raw string concatenation or formatting in SQL queries (SQL Injection prevention).
• 4.2 Verify secure handling of sensitive data (PII, credentials, API keys); ensure zero hardcoded secrets and strict usage of environment variables or secret managers (e.g., AWS Secrets Manager, Vault).
• 4.3 Check user-supplied input for strict validation and sanitization using validation libraries (e.g., pydantic).
• 4.4 Review loops and algorithmic complexity; identify and eliminate potential O(n^2) or worse inefficiencies in high-throughput paths, utilizing generators or vectorized operations where applicable.

---

6. Quality Assurance & Verification Criteria

6.1 Audit Checklist Matrix

6.2 Acceptance Thresholds

• Approval Quota: Minimum of one peer review approval from a Tier-2 certified engineer, and one architectural approval if core domain models are modified.
• Re-review Trigger: Any code modification pushed after a review resets the review state, requiring a targeted re-inspection of altered lines.

---

7. Practical Troubleshooting Scenarios

Scenario A: Unhandled Blocking I/O in Asynchronous Context

• Symptom: The CI performance profiler or code review identifies synchronous file or network calls (e.g., requests.get() or open()) inside an async def function.
• Immediate Corrective Action Protocol:
  1. Reject the PR with the annotation: “Blocking I/O detected in asynchronous event loop.”
  2. Require the author to replace synchronous calls with asynchronous equivalents (e.g., httpx or aiofiles).
  3. If legacy synchronous libraries must be used, enforce offloading to a separate thread pool via loop.run_in_executor().

Scenario B: Dynamic Code Execution or Insecure Deserialization Vulnerability

• Symptom: Bandit flags the usage of pickle.loads(), eval(), or exec() on untrusted input streams.
• Immediate Corrective Action Protocol:
  1. Immediately flag the PR with highest severity (Security Block).
  2. Require the author to replace pickle with safe serialization formats such as json or validated protocol buffers.
  3. If dynamic evaluation is structurally necessary, mandate comprehensive input sandboxing, cryptographic signing, or strict allow-listing before re-submission.

Scenario C: Type Hint Degeneration (Any Type Abuse)

• Symptom: MyPy passes, but the code utilizes pervasive Any type hints to bypass strict type checking.
• Immediate Corrective Action Protocol:
  1. Note the anti-pattern during peer review: “Type safety bypassed via broad Any annotations.”
  2. Require the author to define explicit TypedDict, Protocol, or generic type variables (TypeVar) to maintain strict contract enforcement.
  3. Re-run MyPy in strict configuration to verify type soundness before final sign-off.