Working in VFX, I'd echo the conclusion that there isn't really a standard. It's all over the place with the various software out there. I'd say you're doing all right if you can at least establish your own and stick to it.
As far as left-handed or right-handed coordinate systems, with all the popular 3D software out there ranging from like Unreal Engine to Unity to Marmoset to Maya to 3DS Max to XSI to Blender, it's rather split in my experience with no strong signs of convergence. I think right-handed might be ever so-slightly common in what I've encountered (in terms of world space), but not to the point where I'd even declare it de-facto standard.
When it comes to Y/Z in world space, it is more common in my experience to see Y pointing up/down (vertical) and Z pointing in/out (depth). I suspect the mindset there is to label the world in terms of the initial viewing plane in front view. Yet there are some big dogs like 3DS Max who use Z for vertical, perhaps with the mindset of thinking of world space axis labeling in terms of the ground plane.
Needless to say, lots of time wasted debugging until I realized what the problem actually was.
For this type of thing, and as one who isn't the type to debug code and start drawing out mathematical notes and diagrams on drawing boards figuring out where I went wrong (I envy people who have the patience and mindset to do this, however), I found it very helpful to have like a "visual debug" library where I can temporarily draw lines and planes and axes and so forth (like old school debugging with
printf output to figure out where we went wrong, only with visual outputs to the viewport). It requires some patience of its own as well, but I find it immensely useful in these cases. I've often found with algorithms heavy on the linear algebra that crawling is faster than running and falling into a ditch, to test every single function's visual output for correctness as we're trying to implement something complex. It's like "visual TDD", since I'm often lacking in the smarts to verify correctness in elaborate mathematical ways in these cases short of just seeing if it gives the correct visual output.
A small sample of my own little notes and "visual babystepping" (I have hundreds of these), and if I'm working from a paper I actually try to match their own diagrams of the intermediate steps of the algorithm to verify that I'm implementing it correctly so far. I have little functions like
db_line (draw a debugging line into viewport) along with similar functions to draw labels and points and axes and planes and matrix coordinate systems and such.
Also getting a bit fancy but I tend to prototype these things in script and made it so I can trace through the script line by line and plot what it's doing, one step-at-a-time, into a "debug watch viewport" where I can pan and rotate and zoom around while the script is at a breakpoint to visually examine results as well as plot new things while the script is halted. That might seem a bit overengineered but it was only through building and leaning on tools like this that I was ever able to keep up with the mathematical wizards in my industry. Otherwise I'm the type where if I'm asked to implement an IK solver on a motion hierarchy, I might get the initial implementation 99% correct on the first day only to spend the remainder of the entire week trying to figure out the 1% place where I went wrong in hindsight; with this I can catch those mistakes as I'm making them usually and save so much time.
It's like if I'm trying to test out a complex transformation involving multiple coordinate systems and paths and objects, then I can write a proper automate unit test verifying that the object ends up in the correct place after that series of transformations. But if something goes wrong in the implementation of whatever interface I'm testing and the test fails, I just lack the smarts to debug it without visualizing what's going on. So for me at least, it's so helpful to develop these algorithms in tiny little babysteps where we visually output the result of each little function we write for correctness.
Otherwise if something went wrong, I'd find myself staring at a boatload of numbers in the debugger that look like gibberish to me unless I actually start manually plotting things like points and lines and such on the drawing board, at which point it becomes a lot simpler to just let the computer do that for me and see where I went wrong. So this second part of the answer is not as directly related to your immediate question relating to standards, but I figure it might help for what you're trying to avoid which is spending ages trying to figure out where you went wrong (which is something I find all too common in this domain if we don't kind of test each little teeny step individually).