Tema: 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?
-
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.
-
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.
-
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.
-
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.
-
Code-Review: eine Checkliste für Reviewer
Eine kompakte Prüfliste für Code-Reviews: Zweck verstehen, Design vor Stil, Korrektheit und Randfälle, Tests, Lesbarkeit; Rückmeldung innerhalb eines Arbeitstags und Freigabe, sobald die Änderung den Code insgesamt verbessert.
-
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.
-
Kommentare schreiben, die der Code nicht sagen kann: Gründe, Randbedingungen, Fallen
Ein Kommentar lohnt sich, wenn er etwas sagt, das im Code nicht steht: den Grund für eine überraschende Entscheidung, die äussere Randbedingung, die Falle für die nächste Person. Was der Code sagt, wiederholt er nicht; PEP 8 hält fest, dass Kommentare, die dem Code widersprechen, schlimmer sind als keine. Bevor man kommentiert, prüft man, ob ein besserer Name oder ein Test den Kommentar überflüssig macht.
-
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.
-
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.
-
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.
-
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.
-
Schriftlich widersprechen, ohne zu verletzen: Zitat, Kernpunkt, Alternative
Ein schriftlicher Widerspruch, der eine Entscheidung ändern kann, gibt die Gegenposition zuerst in ihrer stärksten Form wieder, zitiert die strittige Stelle, greift den Kernpunkt an statt Ton oder Person, stuft die eigene Evidenz ehrlich ein und schlägt eine Alternative vor. Paul Grahams Hierarchie des Widersprechens und Googles Leitfaden für Reviewer liefern die Massstäbe.
-
Refactoring in kleinen, geprüften Schritten
Refactoring ändert die innere Struktur, nicht das beobachtbare Verhalten. Ein benanntes Refactoring aus dem Katalog nach dem anderen, Tests nach jedem Schritt grün, bei Rot rückgängig statt vorwärts debuggen, Struktur- und Verhaltensänderungen in getrennten Commits – so bleibt die Arbeit sicher und in Minuten prüfbar.
-
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.
-
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.
-
Vier-Augen-Prinzip beim Deployment: Freigaben technisch erzwingen
Kein Stand erreicht die Produktion, ohne dass eine zweite Person ihn gesehen und freigegeben hat – und zwar so, dass das Werkzeug es erzwingt statt die Disziplin: geschützte Zweige mit Pflicht-Review, Freigabepflicht für die Produktionsumgebung, keine Umgehung für Administratoren, und ein Notweg, der protokolliert statt verboten wird.
-
Cleaning up a branch before review
Before asking for review, squash fix-up commits, split mixed ones and rewrite messages so that each commit is one reviewable change; git rebase -i and autosquash do the mechanical part.
-
Smaller change sets are reviewed faster and with fewer defects
A testable hypothesis: keeping change sets small (roughly under a few hundred changed lines) shortens review time and reduces defects that escape review, with a proposed measurement.
Legível por máquina: JSON