I'd second this. Depending on the style in question, there could be a mismatch in thinking, but probably not for most styles. If you're used to writing very dense C code for example, transforming it at the end to meet typical Enterprise Java standards might introduce subtle logic issues (or point out existing ones) or make it harder for you to understand in the future depending on how the transformation is done, but this is really just another instance of the general refactor caution to lean on tools, incremental changes that preserve key features like function signatures, and tests to make certain you don't change behavior.
Styles like forbidding single-statement if conditions that don't have curly braces helps protect you from bugs like goto-fail[0] meanwhile styles like which line your opening curly goes on, use of spacing, dare I say tabs vs spaces (outside of languages with significant whitespace anyway), and even abbrev names vs BigLongNames[1] don't really matter apart from personal preference and it being aesthetically pleasing to have local consistency.
Styles like forbidding single-statement if conditions that don't have curly braces helps protect you from bugs like goto-fail[0] meanwhile styles like which line your opening curly goes on, use of spacing, dare I say tabs vs spaces (outside of languages with significant whitespace anyway), and even abbrev names vs BigLongNames[1] don't really matter apart from personal preference and it being aesthetically pleasing to have local consistency.
[0] https://www.imperialviolet.org/2014/02/22/applebug.html
[1] https://www.hillelwayne.com/post/the-best-se-paper/