If you are the team leader, then you can (with management approval) develop coding standards that are to be used by all members of your team, and you can also reconcile those standards with the leaders of other teams. If you are not the team leader, then you should privately discuss your concerns with him or her – without naming names. It is not your place to “tell them” anything at all, and your perspective just might be ill-advised in ways that (in your earnest sincerity) did not occur to you.

But also – and this comes from a lifetime of working with “legacy code” and older, recalcitrant projects – do not change existing code just because you think it’s ugly: “stick to your assigned ticket,” and do exactly what is necessary to fulfill the requirements of that ticket. No more, no less. If you think that something ought to be changed, and for more than just cosmetic taste, then you should open another ticket specifically identifying the section(s) and what you think should be done to them and why. But do not then commence work on your new ticket unless and until it is approved by the team leader. Always perform the work, if assigned, on a separate, assigned git branch, and do not merge it until after it has been code-reviewed by a peer and by the team lead.

The reasons for my saying these things are more than simply political – they are technical. Generally, programmers (of necessity) are focused very closely on one small part of a massive piece of source-code; not the whole thing. But there are others, including team-leaders and higher, who are. There should be UAT (user acceptance testing), compliance testing, and possibly many other things – all upstream from you and maybe unknown to you. Your actions, sincere though they might be, could be harmful in ways that you are not aware of. IBM had a term for these kinds of changes – HIPER = HIghly PERvasive.