The formatting is fine, but to me reformatting is not refactoring. Refactoring is using different programming constructs, redesigning abstractions, splitting apart subroutines that grew too big, too hard to test, have too many side effects, or are doing too many things, factoring out common code into base classes, helper subs or modules, shifting over to more appropriate algorithms, that sort of thing. Reformatting is just reformatting; a change in whitespace is inconsequential except to the people who have to read the code. Reformatting is not refactoring.
When to reformat? When you think you've found a formatting technique that will make the code more legible. But in a world with version control, beware that simply deleting a trailing space will mostly just serve to add nose to pull requests making it harder to see the forest through the trees. And will possibly mislead people who come along in the future looking at the code to believing that you modified it when it was only reformatted. For example, I occasionally have to do some large scale moving of code from one layer to another, and in so doing suddenly find my name next to the git blame. A year later someone comes along and asks me questions about it thinking I wrote it. This risk makes sense for substantive changes, but probably doesn't make sense if it's just a matter of tidying up whitespace.
On the other hand, if tidying up whitespace seems like something you wish to do, do it as separate commits from any substantive changes, so that it's easy to identify the important things that changed, versus the shape of the code's formatting.
