# Code Review

> Skill: Code review for TheAlgorithms/Python

- Skill: `thealgorithms/code-review` (Agent Skill)
- Install (CLI): `npx skillmds@latest add thealgorithms/code-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/thealgorithms/code-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: TheAlgorithms (https://skillmd.com/u/thealgorithms)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/thealgorithms/code-review

---

# Skill: Code review for TheAlgorithms/Python

Review a pull request against the rules already written in
[`CONTRIBUTING.md`](../../../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**.
2. 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`.
3. 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:

```text
### 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`