thealgorithms/python/code-review

Skill: Code review for TheAlgorithms/Python

Review a pull request against the rules already written in `CONTRIBUTING.md`. The goal is a review that any reviewer (human or AI) can run the same way every time, and that produces a clear, kind, actionable verdict.

How to run this skill

Read the PR diff, then work through the four CONTRIBUTING.md sections in order and emit the fixed output shape below. Cite the exact rule you are applying and suggest the fix — never just "rejected".

1. Before contributing / Is this an algorithm?

• [ ] The change adds, fixes, or documents one algorithm — not multiple, and

not both code and doctest changes in the same PR.

• [ ] It is a genuine algorithm or data structure (see the What is an Algorithm?

section), not a script, snippet, how-to-use for an existing API, or exercise dump.

• [ ] It is not already in the repository (search the existing directories).
• [ ] No earlier open PR already does the same thing — link it if one exists.
• [ ] Properly attributed — no plagiarism; prior sources credited.

2. Coding Style

• [ ] from __future__ import annotations is not needed because this repo only uses

the latest version of CPython.

• [ ] File and directory names are lowercase, use underscores, and land inside an

existing directory.

• [ ] Public functions/classes have type hints.
• [ ] Public functions have doctests that actually pass.
• [ ] Descriptive variable and function names (no single letters where a word helps).
• [ ] Code is formatted and lint-clean (ruff, pre-commit).

Optional hint: When a PR hand-writes a simple class that is mostly a

bundle of fields (a manual __init__ plus __repr__/__eq__), it is worth

suggesting from typing import NamedTuple or

from dataclasses import dataclass where they would simplify the code. These

are underutilized tools that our contributors would benefit from using where

they make sense. Offer it as an optional improvement, not a blocker — do not

request changes solely because a class was written the longhand way.

When a PR fails ruff check

Don't just report the failure — try the mechanical fixes and recommend the one that works, in this order:

1. Run ruff check --fix file_path.py. If that makes the file pass, recommend

that solution — these are the fixes ruff considers safe.

1. If it still fails, run ruff check --fix --unsafe-fixes file_path.py. If that

makes the file pass and the resulting diff is genuinely safe (it preserves behavior — review it, don't trust it blindly), recommend that solution and note that it required --unsafe-fixes.

1. If neither passes, or the unsafe fix would change behavior, describe the

remaining rule violations and the manual change the author needs to make.

Always quote the exact rule code(s) ruff reports (e.g., ruff rule UP047, ruff rule RUF100) so the author can run those commands to read the rules being flagged. Also, paste the concrete command you ran.

3. Other Requirements for Submissions

• [ ] At least one Wikipedia (or equivalent) URL documenting the algorithm.
• [ ] Docstring explains what the function does and its parameters/returns.
• [ ] No unnecessary third-party dependencies.

4. Verdict — fixed output shape

Emit exactly these headings so reviews are comparable and easy to automate:

### Is this an algorithm? — <yes/no + one-line why>
### Duplicate / prior-art check — <#NNNN | none found>
### Coding style — <pass | issues: …>
### Other requirements (doctests, type hints, descriptive names, Wikipedia URL) — <pass | issues: …>
### Verdict — <approve | request changes | close> + one-line reason

Tone

Be specific and kind. Point at the exact CONTRIBUTING.md rule and offer the fix rather than a bare rejection — first-time and Hacktoberfest contributors are more likely to come back and improve the PR when the path forward is clear.

Map findings to labels

Where a finding matches an existing label, name it so the review lines up with the maintenance/cleanup tooling:

• missing/failing doctests → require tests
• missing type hints → require type hints
• non-descriptive names → require descriptive names
• CI red → tests are failing
• otherwise ready for a maintainer → awaiting reviews