I think the best practice as a mapmaker is to abstract all triggers outside the map itself.
This means you should edit and create triggers in a separate IDE, ideally a programming one like PyCharm, rather than the clunky GUI editor. The other advantage is
version controlling your map code. You should keep your triggers in GitHub repository or similar place, and treat it like a real technical project. There is a lack of "respect what comes before" in the community, because mappers do poor jobs of abstracting triggers and sharing them in common formats. For example, I should be able to get the triggers for Desert Strike from a GitHub repo and not need to ask the mapmaker or unprotect the map/extract from the chk, etc.
So for me, these are key to being a good map maker:
1. Write all triggers in external text editor/IDE (use one of the many trigger macro languages). I recommend knowing Python for this.
2. Version control your map's code, ideally using Git.
3. Add comments to all your triggers. You will thank yourself if you ever take a break and try to come back to your project in 6 months.
4. Be sympathetic to your "customers", which in our case is the players and maybe anyone who uses your map for their project.
What I am bad at:
1. Terrain. I'm just not an artist.
2. EUDs. I am a programmer by profession but I really don't grasp hacky low level operations on memory to create new behavior in SC.
I end up struggling with the trigger editor and wasting time to copy the same trigger for all players for different locations. I still have an annoyance with the user interface taking up more than 5% of the map's size.
This is why I created
YATAPI which is a Python API for writing TrigEdit triggers. It's nothing fancy, but it lets you write all the triggers outside the editor. It would solve many of your issues. You would write the same code in one place for your trigger, and then iterate over parallel arrays of players/locations to create triggers for each player/location pair (net same number of triggers, but on your end it's just one trigger macro). There's an example in YATAPI just for that use case.
None.