I looked at rewording the routine after I noticed how long it was taking in the trace window. I came up with something similar to what you posted, but decided to revert to the original layout because I thought the code read better. (On looking at your code though, I think they just read differently depending on how you originally approached the problem.)

I question your second point about storing intermediate values though. From my experience storing intermediate values has little to know affect on speed (depending, of course on how excessive you get). Sometimes storing intermediate values can increase speed.

The way that I have always figured it worked internally (correct me if I am wrong) is that even if you are not storing the value in code, VFP is internally. If you store and reference a value as opposed to letting VFP try and figure out itself if it needs to recalculate, this can often result in better performance.
Most of this doesn't directly apply to the routine in question, but this does:
I never sacrifice readability for marginal performance gains.

Thanks for the tip.

>Erik,
>
>You should note that exponentiation is one of the slowest operations for the CPU to execute. Your routines will be a little faster if you just use a simple variable and multiply or divide it by 26 in each iteration. Also the second routine where you store intermediate values takes a lot of unneeded time.
>
>This ends up being quite a bit faster:
>
>

FUNCTION Base26ToBase10
>LPARA tcStartCode
>LOCAL lnResult, i, j
>
>lnResult = 0
>j = 1
>FOR i = LEN(tcStartCode) TO 1 STEP -1
>	lnResult = lnResult + ( ASC( SUBSTR(tcStartCode, i, 1) ) - 65 ) * j
>	j = j * 26
>ENDFOR
>
>RETURN lnResult