Just write a script that does the chown's recursively - or do as I do - I just fix it in term after I complete the editing. Once you have the commands in term, you just scroll back through the command line history.
I have done three things to make my life easier -
One - despite all the blah, blah, blah pussyfooting in the oh so correct Linux world about SE Linux and all, I created a root login because that was easier for system fixing/updating/compiling etc. BUT i rarely use it.
Two - I don't care for 'sudo', I much prefer 'su' which creates a root shell. then I don't have to mentally do gymnastics.
Three - I learned to launch geany from the command line (after su) so I am 'root' until I close that geany session. When you write the file it will be owned by root:root
When I'm done editing and want to test, I open a new session/window in Term, make myself 'root' via su, and use the right chown syntax to flip the ownership to nobody:root.
The real issue is that the owner of the Apache worker processes (not the listener) must be the owner or a member of the group that owns the files that are in htdocs or aliased folders that contain vhosts or code. This does not apply only to XAMPP, its a generalized Apache issue. Its to prevent the worker processes from executing code as root.
if you google "apache files owned by root" you will find some pretty good explanations out there. The problem with all the explanations is that they rely on a standard 'LAMP' stack having been built, where all the parts are in the right places, and the OS has some idea what is installed and what is not, and the runtime environment is drive by 'the usual suspects' for any given Linux distribution. Most of those explanations/suggestions fall flat because 'lampp/XAMPP' isn't constructed that way. BUT the comments about why root should not be the owner, and why it is best to create a 'special' user are valid. AND - the kind authors of the lampp bash script did just that - there is a special user in Linux/Unix called 'nobody' - and they used that tactic to create lampp. Bear in mind also that shared Linux hosts have their own set of issues (multi-tenancy) so things are different between 'shared' hosts where from a Linux POV, there are many users on the systems and a single instance of most 'server' processes such as mySQL, Apache, FTP etc. and 'your own box' or a VPS where effectively there is only a single 'dedicated' client (which vastly reduces security and operation/performance concerns).
If its 'your' box and you are not sharing it with other users, I can't see any particular advantage to placing the files in /home/youruser/yourprojects - I do all my work right in htdocs and in project folders I create in the root of the filesystem (and then alias them) it makes the command line navigation a lot faster.
I should also say that I work by necessity with standard Linux LAMP stacks as well, because that is what you find on client's servers whether they own them, or have VPS's or KVM. So I use VirtualBox (excellent) and keep 5 or six flavors on tap locally so I can test before deploying. I have two servers that run lampp locally as a pure install over Fedora.
These are all just my opinions, so you have to guide yourself.
I hope this has been helpful, and good luck with your projects.