✳flâneur — a map of the web's best reading

Unified Versus Split Diff

matklad.github.io · 454 words · saved by 1 readers

If the changes are simple and small, both views are good. But for larger, more complex changes neither works for me. For a large change, I don’t want to do a “diff review”, I want to do a proper code review of a codebase at a particular instant in time, paying specific attention to the recently changed areas, but mostly just doing general review, as if I am writing the code. I need to run tests, use goto definition and other editor navigation features, apply local changes to check if some things could have been written differently, look at the wider context to notice things that should have been changed, and in general notice anything that might be not quite right with the codebase, irrespective of the historical path to the current state of the code. So, for me, the ideal diff view would look rather like this: On the left, the current state of the code (which is also the on-disk state), with changes subtly highlighted in the margins. On the right, the unified diff for the portion of t

Which is better for code reviews, a unified diff or a split diff? A split diff looks like this for me: And this is a unified one: If the changes are simple and small, both views are good. But for larger, more complex changes neither works for me. For a large change, I don’t want to do a “diff review”, I want to do a proper code review of a codebase at a particular instant in time, paying specific attention to the recently changed areas, but mostly just doing general review, as if I am writing the code. I need to run tests, use goto definition and other editor navigation features, apply local c

Explore this link on the map →

related reading