Use cases / Anyone reviewing a reorganisation
Large refactors that hide a behaviour change
A refactor is supposed to change nothing. Find the one line that does.
The problem
Renames and moves make the diff enormous while the risk lives in two lines. Reviewers either read everything or nothing.
What visualdiff does
- Pure renames and moved blocks are detected and skipped.
- Whatever remains, the lines that really changed, goes to the top of the plan.
- A refactor that touches public interfaces is flagged: refactors usually change behaviour there.
In the sample, a rounding change from round to floor is the only real edit among nine renames.
Related
- Reviewing pull requests written by agentsAgents open pull requests faster than anyone can read them. Read the 10% that decides whether it is safe.
- Stopping hallucinated dependenciesSlopsquatting: attackers register the package names models invent. Catch them at review.
- Seeing which running systems a change reachesThe diff says rds.tf. The map says orders-db, the API in front of it, and the queue behind it.
- Knowing whether review is keeping upThe sanity index: is the codebase getting harder to review as more of it is written by machines?