I've talked before about the codebase consistency using a common code style for the entire team.
But programming is an expressive endeavor. Even the most strict code style cannot make the entire code base uniform when multiple people are working on it.
This is especially noticeable in a "module" within the codebase where one or a small number of people have been almost exclusively contributing for some time. The module might be completely compliant with the agreed code style but still, have its own unique "style".
For instance, within the module, you might notice that calculations are executed on variable getters the first time they are used. But you have usually performed these calculations in the constructor to be ready when needed. Performance-wise this is quite similar (assuming the calculation results will be used anyway soon after initialization). The code style does not mention anything about this case (and rightly so).
So when you are asked to contribute to that module and notice this implicit style, what do you do? Most of the time you might think that your way of doing things is better / more performant / more readable.
But usually it's just different styles. And as a good citizen of the codebase, you should respect the style of the module.
Over the lifetime of a module (hopefully many years before a rewrite is needed) probably a handful of engineers will contribute. Just imagine what a mess would become if every engineer just ignored the module's style and made a change using their own coding style. The module would soon become quite difficult to parse. Even if it fully adhered to the team code style.
The alternative, if you strongly believe that the module's style is terrible, is to completely "migrate" the module to be self-consistent to a new (your) code style. This would require way more time commitment but at least would leave the module in a consistent state. So think carefully if the code style is indeed terrible or just different from your own.
Hopefully, I gave some food for thought when contributing to modules you don't own within the codebase.