I think the author is overthinking it in the second section: we're not discouraging deleting code by marking it red. We're simply denoting that it was removed, or killed off (he drew the connection of red to blood, and green to new life).
However I don't understand why diff views abandon syntax highlighting. I understand there's sometimes a challenge of breaking up highlighting that depends on syntax that spans multiple lines, but it seems like we could do better than marking entire lines bright red and green and leaving the text black. This is the biggest thing that confuses me about Github - they've left it like this for years and it's probably the most looked-at part of their site.
Yep. And it's mostly about communicating. That they choose red for removals and green for insertions is meaningless. We may argue the same nonsense about stop lights. A parked car is safe a moving one can kill. So let's replace the stop lights colors. What? Yeah. Silly argument. The colors do not matter at all. Sometimes a cigar is just a cigar.
When programmers all around the world look at the red/green in a diff they understand it, without having to search for a legend explaining the colors.
This is something that most code review tools apart from GitHub get right. For example Critic, Review Board, Phabricator and Gerrit all implement side-by-side diffs with correct syntax highlighting on each side. I don't know why the GitHub experience is so far from the state of the art.
I would imagine it's easier to do syntax highlighting on side-by-side, because you can just reuse your existing syntax highlighter. But when presenting the `-/+` style of diff, you need a custom syntax highlighter that not only can skip over the `-/+` tokens but can also handle having two separate-but-intertwined non-contiguous highlighting states (because the `-` lines will be using a different state than the `+` lines).
And then what do you do if the state ends up different when you hit the context lines again? There's no obvious choice as to how to highlight those.
Right, so the question is "why not have side-by-side diffs". The fact that syntax highlighting would work is one obvious advantage. It also means that you can read the before/after code linearly without having to mentally apply the patch. It seems like an obviously better UI for understanding the effect of changes (although of course I don't have data to back that up).
I would like to see GitHub offer the option of seeing side-by-side. It can be helpful if you have a mess of tiny -/+ hunks right next to each other. But combined is definitely the correct default.
What do you mean? First off, you're making the assumption that your highlighting library gives you results that can be trivially split per-line (e.g. no styles cross line boundaries, line boundaries are easy to find, etc). I haven't worked with web highlighting libraries so I don't know if that's true. But let's say it is. Now how do you handle the problem I called out, where the context lines are highlighted differently in both versions? You only show the context lines once in a combined diff.
However I don't understand why diff views abandon syntax highlighting. I understand there's sometimes a challenge of breaking up highlighting that depends on syntax that spans multiple lines, but it seems like we could do better than marking entire lines bright red and green and leaving the text black. This is the biggest thing that confuses me about Github - they've left it like this for years and it's probably the most looked-at part of their site.