I stumbled upon the most ridiculous article tonight. The author claims diff viewers are wrong for displaying deletions in red and additions in green. Why? Because, he says, that is tantamount to passing a value judgment, red being associated with evil and danger, and green with good, and all:

Our diff viewer, then, tells us that deletions are bad, dangerous, and possibly an error, while insertions are good, safe, and successful. More code good. Less code bad.

At this point we know the article is utterly flawed, because of course it is not the deletions that are colored red by diff viewers such as GitHub’s. It is the old code. The author acknowledges this objection:

Edit: multiple people have suggested a different interpretation: old code bad, new code good.

But he still tries to save his argument:

However, since that would be a similarly invalid value judgment, the argument below is still valid.

Invalid value judgment? Why, of course the old code is bad, or at least worse than whatever replaced it – hopefully! Otherwise, why would we have deleted it? Perhaps what the author is thinking about is that we may have made a mistake and don’t know whether we really improved the program:

In reality, insertion/deletion is orthogonal to good/bad. There are good insertions, good deletions, bad insertions, bad deletions. Only we humans get to judge which changes are good and which are bad, but during code review, the diff viewer is constantly subtly trying to influence our judgment.

But he got it all backwards. A human already made the decision that the old code is bad, and the diff viewer had better be doing its job and reflect that judgment! Software cannot spot the programmer’s mistakes – it should make her intent clear so she or others will hopefully notice.

As far-fetched as the author’s complaints about diff viewers trying to influence our judgment is his theory of why red came to accompany deletions and green, additions:

I believe the reason for this strange color scheme is the lack of a revision control system. Back in the dark ages of programming, we didn’t use them. We edited files on disk, and that was that. In that environment, a deletion is dangerous. (…) But we don’t live in a world without revision control. It is peculiarly ironic that the ‘deletion is dangerous’ sermon is being delivered by our version control systems. That same revision control system which tells us that ‘it’s okay to delete things, because it’s all still there in the history.’

Far from it – there are still very good reasons to associate deletions with danger, and therefore, the color that stands out the most (red). Philosophically appealing though the author’s God-like perspective on revision histories may be – there is no time, all is one, deletions and additions are just the same thing seen from two sides – in reality, software development still happens from past to future.

This firstly means that deleted lines are, though not lost, quickly forgotten – and hopefully for a good reason. Highlighting them in a color that warns us to check our deletions carefully helps avoid relegating important stuff to history and later not being able or bothered to retrieve it.

Secondly, the function of a diff – at least the type that the author shows us, which is not side-by-side – is not to show us an impartial view between two versions of equal status. What we are typically interested in is the new version and how it compares to the previous one. And the new version is right there: it consists of the white and green lines. The green ones are marked for being new, but other than that are not really different from the white ones. In addition, there are red lines showing us what was deleted. Mistaking a red line for part of the new version would be dangerously misleading – hence, again, the signal color.