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.
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").