Re^2: Refactoring technique?

[BrowserUk]

Not sure what your question is. Just naming of parameters?

Yes & no. Imagine you're the programmer charged with looking at this code (see the spoiler) a couple of years from now, and you're trying to make sense of $text1, $text2, & $text3 in context.

If they have specific roles, find a name corresponding to that role.

Again, take a look at the code in spoiler. Can you see a "name corresponding to that role"? <P.Or for a better sense of the scale of the problem:

• look at the original code;
• find the function called _BoundingBoxDraw();
• and then look for the 6 blocks that begin with the line:<code>gg=_GetGrid( ... );</c>

The 3 parameters need to be substituted everywhere that x, y, or z are used within that block, but sometimes the first parameter will be the x component of all the things; sometimes the y; sometimes the z; and so on for the other two parameters.

Within the context of 3D code x, y, z give some sense of what the thing you're dealing with is; text1, text2, text3 don't.

Similarly, for u, v, w; but it's worse, because you intuitively think of them as being placeholders for x, y, z respectively, but they aren't. Or rather sometimes they will be but mostly they will be some other ordering.

Similarly, if you use numbers -- say $xyz1, $xyz2, $xyz3 -- we tend to associate them to some ordering, even though we know that any one of the formal parameters could be any one of the actual parameters.

Its just something that has recurringly given me pause for thought each time I've encountered it down the years and I've never really come up with a good solution/approach to the problem.

[hdb]

Now I got you. For my education (I have never used js), how do you parameterize x, y and z anyway. You have a lot of something.x and somethingelse.y. If you would want to write doStuff( u, v) how would you use u and v in the code?

[BrowserUk]

how do you parameterize x, y and z anyway. You have a lot of something.x and somethingelse.y.

I'm still getting to that, but it seems that in JS, any place you can write o.x you can also write o['x'], so, I'm hoping that by extension, instead of:

function doStuff( x, y, z ) {
    ...
    oo.x.thing = p.y.max * qq.z.min;
    ...
}

I can also write:

function doStuff( a, b, c ) {
    ...
    oo[a].thing = pp[b].max * qq[c].min;
    ...
}

I'm still cleaning up and refactoring other parts, so I haven't tried that yet; but from what I read, and a couple of small tests, I think it will work.

If any JS guys are following along and can verify that (or not), I'd be grateful.

[jeffa]

Lucky for you that want the oo[a] notation instead of oo.x notation. I am mostly positive that Javascript cannot interpolate a method call at runtime. Consider the following:

#!/usr/bin/node

var key = 'id';
var obj = { id: 123, key: "wrong key!" };

function do_meth( obj, key ) {
    return obj.key;
}

function do_windex( obj, key ) {
    return obj[key];
}

console.log( do_meth( obj, key ) );
console.log( do_windex( obj, key ) );

When run, do_meth returns "wrong key!" instead of 123. You have to hard code return obj.id ... or use bracket notation such as you desire.

[hdb]

I have been meditating over your original code. I cannot say what it does but the generalstructure looks like this: there are three sections, one for each plane. I would call that parameter $plane. In each of the three sections, there are three subsections: some prep stuff involving the two other directions in the same way and then two sections that you seem to want to refactor into doStuff. Each section needs both other directions but starts dealing with one of them first. For example, in tge z plane section it first deals with the x axis, then with the y axis. I would therefore call one direction $primary and the other $secondary. So in summary it would be doStuff( $plane, $primary, $secondary ).