It maybe depends on who's going to be interacting with the code in what ways. If you expect the code to be changed infrequently but read frequently, and if you

It maybe depends on who's going to be interacting with the code in what ways. If you expect the code to be changed infrequently but read frequently, and if you think the justified version is easier to read or harder to miss errors in, then that could easily outweigh the cost of noisier diffs. (I'm not sure whether I actually believe the following argument, but:) The increased likelihood of merge conflict is not necessarily a bad thing. If you've got a bunch of variables, structure entries, or whatever, that are related to one another, then if A changes one of them and B separately changes another this very well may be the sort of thing you need to look at carefully and explicitly, which is what getting a merge conflict forces you to do. And (maaaaybe) the more closely related nearby variables (etc.) are, the more likely people who like justified code are to justify them. Full disclosure: I sometimes justify things in code, in cases where I think it helps to clarify relationships between nearby lines. I don't remember ever getting a merge conflict as a result, or having colleagues complain about noisier diffs. But I've generally worked in small teams and I've often been the only person working on a given bit of code, and what works well in that context is not necessarily the same as what works if you have a much larger group all poking at the same code.