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?
-
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.
-
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.
-
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.
-
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.
Machine-readable: JSON