Also, "you should code like that because that's how we code here" isn't a good reason. If you don't have a good rationale for the changes, I would consider not making them.
On the contrary, that is a very good reason, and sometimes the only one that matters.
In any group of "n" developers there are likely to be "n+m" different ways to do the same thing. This increases the "cognitive load" to understand others' code (a fancy way of saying it makes the code hard to understand).
Personal preference is not a valid reason to eschew standards, even (especially) de-facto ones.
If there is a "better" way to accomplish a particular task, then the entire team should adopt it (and go back and change existing code to conform to the "better" approach). If that's not worth doing, then leave well-enough alone. (Another way of saying "If it ain't broke, don't fix it").
Right, but simply saying, "that's the way we do it here" doesn't communicate all that. Hence, "that's the way we do it here" is not a good reason. "That's the way we do it here, and here is why we do it like that..." is how it should be phrased.
In any group of "n" developers there are likely to be "n+m" different ways to do the same thing. This increases the "cognitive load" to understand others' code (a fancy way of saying it makes the code hard to understand).
Personal preference is not a valid reason to eschew standards, even (especially) de-facto ones.
If there is a "better" way to accomplish a particular task, then the entire team should adopt it (and go back and change existing code to conform to the "better" approach). If that's not worth doing, then leave well-enough alone. (Another way of saying "If it ain't broke, don't fix it").