When you start working on a new (for you) but existing codebase, you will notice patterns you strongly disagree with. Naming conventions that seem stupid. Abstractions that seem over-engineered. Error handling that you would have done very differently.
Match them anyway, in the code that you write.
A codebase is a shared ‘language’. When every file follows the same conventions, you and your peers can move through the code quickly, make changes confidently, and reason about what things do without stopping to decode style differences.
The moment you introduce your own patterns, you add a ‘second dialect’. Now the next person reading your code has to context-switch mid-file.
The cost of diverging is almost always higher than the cost of going along with something imperfect. The original author is not necessarily wrong either - they had context you do not. Try to understand that.
There is a right time to change conventions; wait until then. You can always initiate a team discussion or raise a smaller pull request that updates a small fraction of the codebase and demonstrates the benefits.