There used to be a comment here with a bit of explanation of what parameter is what. I think that's still a good idea here (but possibly a completely different comment because behaviour changed).

End sentences with a period. The comment could also be put on two lines, I'm guessing.

This block is indented too much. If pchan == NULL or conlist == NULL you can just return. This saves two indent levels.

This should be a switch statement, and not a sequence of if/elseif.
Every case should be its own properly-named function, with clearly named parameters.

The next code block (i.e. empty-line-delimited bit of code) doesn't mirror anything, so the comment is a bit weird here.

What does it mean to "represent X"? This code seems to find the matrix row with the largest first value, but it's not clear why this is even relevant.

Where is this mapped? What defines those values? Where do they come from? So many magic numbers.

Why not write min_vec[0] = -min_vec[0]? Or write min_vec[0] *= -1? Personally I prefer the latter, as it's clear at first glance that it's only taking the negative (so no swapping min/max or changing the index).

Just declare int i as part of the for-loop (so for (int i=0; ...). Outside of a for-loop it's a rather horribly-named variable.

act doesn't change within the for-loop, so you can do the DEG update outside the loop.

Unclear why the 'min vector' and 'max vector' are relevant concepts at all.

Bit of a weird choice in empty lines here, possibly better grouping possible?

Same as above, just do if (ob->pose == NULL) { return; }

Same as before, probably can use continue here. Patch wasn't submitted with Arcanist, so I can't see outside it (no context available), so maybe this is not the case.

Just *= -1 those

It's not clamping, it's modulo'ing. And yes, that's a good thing to do. In a separate function, in BLI_whatevermath.

Once working on it anyway, you may want to add two normalisation functions, one producing a result on the interval [-180°, 180°), and one on [0°, 360°).

Add something like "This code assumes that bRotLimitConstraint and bLocLimitConstraint have the same fields in the same memory locations."

Possibly it would be prudent to add a similar warning to the types themselves, pointing back at this code.

Don't use mat or imat, but give them a descriptive name, something that is a bit closer to "constraint space conversion matrix".

tar → target

own, imat → something more descriptive

Why not just = -old_max?

Don't name things temp, but describe what it is. The fact that it's here in an if in a loop in an if already shows that's temporary.

Declaring where it's needed and then naming descriptively ('copy of scale' is likely better than 'temp vector') is better.

switch!

You could even go further and de-uglify it locally a bit by #define AXIS_X 0 and the like (or use a const char for that). That way at least we have some understandable word there, instead of just a 0.

Code style: use underscore instead of camel case

The previous comment here was clarify what src_ob and dst_ob was used for.

Now this function simply does what the name suggests, it updates the bone duplicate constraint sub-target.
I don't think this need any further explanation as it would be akin to:

/* add 'a' and 'b' together  and return the result */
float add(float a, float b)

This is copy pasted from other parts of the animation system in blender.

If we wish to update this, it should be done in a separate commit.

This is because I can't initialize both i and bezt in the for loop then.

I have moved down the declaration to just above the loop instead to make it better.

This is so we can easily transform the min/max values of the constraint.

Grouped by min/max values. I don't see any better grouping here.

In this case, the variable is used to store values temporary.

It stores loc/rot/scale data depending on how the constraint is mapped.

Can't use continue here. I have resubmitted the new revision of the patch with context.

Shouldn't this use head[axis] instead?

This is what the spaces are called in the constraints themselves.
So I think that these are descriptive enough.

Right you are!