return xxx;

is the way to go

At an earlier point in my career, I often changed code in similar ways. Worse, I reformatted nearly everything I touched. Ultimately, this is a lot of “fire and motion” without real benefit. It is very rare that someone formats their code in ways which are truly difficult for me to read.

In working with others and using source control, I’ve come to appreciate commit logs which are “clean” and communicate only the “significant” changes. If I have a really good reason for wanting to reformat or rearrange a bit of code, I reserve such changes for separate commits.

That said, there is a line of reasoning you can take behind performing some of the latter changes you’ve described above, beyond style. I believe it’s explained in “Code Complete” (highly recommended reading!)

The short of it is, you put your gating factors (trivial rejections, etc.) at the top of a function, to quickly return or escape from unnecessary processing. Then you allow the common case to occupy the “root level” of your function. The idea being that the normal flow of control should not be nestled away in conditionals (especially deeply nested ones!) Any given function has a specific purpose (if you adhere to SRP) and that purpose should read as simply as possible in the “most expected” location.