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.
Good God, give this guy a configuration option for the colors – old code in purple, new code in orange, or whatever…!
But the viewer will reflect the judgement of whoever made the decision, not necessarily that of the person who is looking at the results and who might actually distrust the one who made the changes. So if you had changed the code yourself you might want the colours the way they are, but if I had you might actually prefer them the other way round.
So it actually seems that TocTocTocToc’s solomonic solution might be called for after all.
Does it matter? You’ll still want to know what they thought was bad.
I’m not sure, just playing the devil’s advocate here. But I understand that the argument iss that the colours subtly influence the judgement of the one who views the changes. If that is right (which I do not claim) then you would be subtly influenced by the diff viewer towards thinking I did a good job, while you in fact think I did not.
I only remark this because I do not get the impression that you reject the subtle-influence-hypothesis right away but rather claim that the influence is just right. And this does not seem obvious where the influence is in favour of someone else’s possibly bad jugdgements.
The author’s original claim is that red-and-green diff viewers make us think deletions are bad and additions are good. That would mean that the viewers influence us towards keeping as many lines of code around as possible. So an empirical investigation should be able to show that there is a positive correlation between use of such diff viewers in developers, and being reluctant to delete lines. I highly doubt such a correlation can be found (but that is just a gut feeling, of course).
If we instead take the view that red-and-green diff viewers make us think deleted code is bad, and added code is good, I think this is highly implausible even without looking at empirical evidence. Because that would be an influence in favor of every code change, no matter its nature. So that would not really be any bias at all, would it?