Topic: code-review

• Which code-review metrics predict escaped defects without being gamed?

  Open question: review turnaround, comment density and change size are easy to measure, but which of them actually predict defects found after merge, and which stop working once teams optimise for them?

  question · en · reviewed · knowledge as of 2026-09-15

• Privacy review checklist for a feature

  Ten questions a reviewer answers before a feature ships: inventory of new personal data, minimisation decisions, retention job, access and access logging, export and deletion coverage, preference purposes, third-party flows, a short LINDDUN pass, test data, and a recorded result; engineering properties only, no legal assessment.

  methodology · en · reviewed · knowledge as of 2026-09-17

• Automated formatting and linting as a team contract

  Delegating layout to a formatter and mechanical checks to a linter removes style debates from review; EditorConfig, PEP 8 and tools such as Ruff show how the contract can be encoded in the repository.

  methodology · en · reviewed · knowledge as of 2026-09-15

• Describing a change so that reviewers can review it

  A change description states the problem, the approach and its alternatives, how it was tested and what reviewers should look at; it links the ticket and lists risks and follow-ups, so review starts with understanding instead of archaeology.

  methodology · en · reviewed · knowledge as of 2026-09-15

• Reviewing code written by an AI agent

  A proposed review protocol for generated changes: compare the diff with the request, confirm every API and dependency exists, verify test claims by running and breaking the tests, read tests before implementation, hunt for swallowed errors, and record what was checked.

  methodology · en · reviewed · knowledge as of 2026-09-15

• Code review: a checklist for reviewers

  A compact checklist for code reviews: understand the purpose, check design before style, then correctness and edge cases, tests and readability; respond within one working day and approve once the change improves the codebase overall.

  methodology · en · reviewed · knowledge as of 2026-09-15

• Recognising code smells before refactoring

  Code smells are surface symptoms (long methods, large classes, feature envy, shotgun surgery, primitive obsession) that suggest a deeper design problem; naming them gives a vocabulary for review and a trigger for refactoring.

  article · en · reviewed · knowledge as of 2026-09-15

• Writing comments the code cannot say: reasons, constraints, traps

  A comment is worth writing when it says something the code does not: the reason for a surprising decision, the external constraint, the trap for the next person. It does not repeat what the code says; PEP 8 states that comments that contradict the code are worse than none. Before commenting, check whether a better name or a test would make the comment unnecessary.

  methodology · en · reviewed · knowledge as of 2026-09-16

• Invisible and reordered text: bidirectional controls, tag characters and confusables in code and prompts

  Unicode lets text contain characters a reviewer cannot see or that reorder what is displayed. Bidirectional controls can make source code read differently from how it compiles, tag characters can hide instructions that a model still receives, and confusables imitate identifiers. Detection means scanning the code points, not the rendering.

  methodology · en · reviewed · knowledge as of 2026-09-23

• Conducting a code review that improves the code

  A reviewer's procedure derived from Google's engineering practices: judge whether the change improves overall code health, review design before style, and keep turnaround within a business day.

  methodology · en · reviewed · knowledge as of 2026-09-15

• Running a design review: comment period, named decider and a recorded disposition

  A proposal review needs a bounded comment period, a named person or group who decides, a written disposition (accept, reject, postpone) with reasons, and a rule for reopening; the Rust RFC process and Python's PEP process show the shape and this methodology adapts it to a single team.

  methodology · en · reviewed · knowledge as of 2026-09-16

• Disagreeing in writing: steelman the position, then refute the central point

  A written disagreement that can change a decision restates the other position in its strongest form, names exactly what is disputed, quotes the mistaken passage, gives graded evidence, and proposes an alternative; Paul Graham's disagreement hierarchy ranks replies from name-calling up to refuting the central point.

  methodology · en · reviewed · knowledge as of 2026-09-15

• Keeping reformatting commits out of git blame: -w and ignore-revs files

  git blame -w ignores whitespace when tracing lines, --ignore-rev and a committed .git-blame-ignore-revs file skip named commits such as mass reformattings so lines are attributed to the previous meaningful change, and -M/-C follow moved or copied lines; GitHub reads the same file automatically.

  article · en · reviewed · knowledge as of 2026-09-16

• Disagreeing in writing without causing offense: quote, core point, alternative

  A written objection that can change a decision first restates the opposing position in its strongest form, quotes the disputed passage, attacks the core point rather than the tone or the person, rates its own evidence honestly, and proposes an alternative. Paul Graham's hierarchy of disagreement and Google's guide for reviewers supply the standards.

  methodology · en · reviewed · knowledge as of 2026-09-16

• Ranking code-review attention with Jev without averaging away blockers

  Use separate review dimensions to prioritize human attention while retaining mandatory checks that a weighted score must never override.

  methodology · en · reviewed · knowledge as of 2026-09-22

• Refactoring in small, verified steps

  Refactoring changes the internal structure, not the observable behavior. Apply one named refactoring from the catalog at a time, keep the tests green after every step, revert instead of debugging forward when they go red, and keep structural and behavioral changes in separate commits, so the work stays safe and reviewable in minutes.

  methodology · en · reviewed · knowledge as of 2026-09-16

• Snapshot and golden-file tests and how to keep them honest

  A snapshot test serialises an output and compares it with a stored reference; it covers everything and describes nothing. Keep snapshots small, normalise volatile fields, review snapshot diffs like code and update them selectively, or they decay into approved noise.

  article · en · reviewed · knowledge as of 2026-09-15

• A security-focused code review checklist for changes at trust boundaries

  A short list of questions a reviewer asks of any change that touches input, authentication, authorization, data access, outbound requests, files, secrets or dependencies: where does the untrusted data enter, who is allowed to do this, what does it query, where does it send or store, and what is logged. Applied to boundary-touching changes only, so that it stays short enough to be used.

  methodology · en · reviewed · knowledge as of 2026-09-16

• Four-eyes principle for deployments: enforcing approvals technically

  No build reaches production without a second person having reviewed and approved it, and the tooling enforces this rather than relying on discipline: protected branches with mandatory review, an approval gate on the production environment, no bypass for administrators, and an emergency path that is logged rather than forbidden.

  methodology · en · reviewed · knowledge as of 2026-09-15

• Mapping a code-review claim to the exact changed behavior it supports

  Build a compact review map that prevents unrelated passing checks from being used as evidence for a newly changed behavior.

  methodology · en · reviewed · knowledge as of 2026-09-22

Next page

Machine-readable: JSON