I want to check if this is the expected / usual behavior before submitting a bug report.

When I copy a parameter and paste a relative ref into a wrangle, it clears all of the other code and just leaves the copied reference. I'm pretty sure this doesn't always happen but seems to be consistently occurring at the moment, even when creating a new file with a simple-as-possible example. Also sometimes it's not letting me undo after this, although that's not consistent.

I know I can work around this by creating a chf and pasting the relative ref into there, but prefer to skip this step. And if added manually the relative references do work in the code so there doesn't seem to be a reason for overwriting everything else unless I'm missing something.

I'm pretty sure that's normal. They added in concatenation to the existing expression a while back, but I think it's only for float parameters.

Pasting relative references into a wrangle doesn't make sense under ordinary circumstances, as the wrangle contains vex code, but a relative reference is in hscript. I would stick with adding a parameter to contain the relative reference, and using the relevant ch() function in the vex snippet.

Thanks - I guess that's why the references are contained in ``.

So would it be considered bad practice to have code like this? Is there a chance it can cause problems or is it just not clean code?

float distanceFromInner = length(@P) - `chs(“../planet_rad”)` - `chs(“../ring_dist”)`;
distanceFromInner = clamp(distanceFromInner,0,`chs(“../ring_wi”)`);

clem.lysergy
So would it be considered bad practice to have code like this? Is there a chance it can cause problems or is it just not clean code?

It causes the source code to become dynamic, each time the value changes, the source will need to be recompiled. This can lower performance substantially.

It's bad practice because there are more performant alternatives. Intead of `chs(“../fooname”)` and `chs(“../barnumber”)`, chs(“../fooname”) and chf(“../barnumber”) will do the job faster and make the code cleaner. There are a few cases where it's okay such as when it is desired to have dynamic code. e.g. when the type of a variable is controlled by a parameter, or the entire source code is built programatically.

on top of what was said, the parameters referenced as expressions used to build the snippet code can't be animated since the code string is expanded on the first frame and compiled
so it really only makes sense to use them to build the snippet code for flexibility and optimization reasons

personally I'd further advise against using VEX ch*() functions pointing to different than current node as they are not creating traceable dependencies and it makes such wrangle more difficult to reuse as a standalone node