Nadya,

Personally, I would put this item at the end of the potential optimizations list. Even then, after other things might have been done, I'd look again at if these things need changing.

But I also want to point out that "documenting" is documenting and "optimizing" is optimizing.
My practise is to keep it simple, so when I optimize I opitimize and when I document I document.

In my opinion, if what you want/need to do is to document, then changing **ANY** of the (active, executing) code should be a no-no. It would be fine to add/revise COMMENTS in code as you document the thing (though even that needs, of course, testing after doing to ensure continued correct execution).

If you feel the need to optimize then my suggetion is to optimize FIRST, get that out of the way (completed, tested) and then do the documentation.

Just one opinion.


>Hi everyone,
>
>I am documenting one old project of mine and while doing it, I am going through the code and making bunch of optimization changes (wondering, when I finish, would it be worth anything? :)) Anyway, here is the situation [I'm using VFP6]: I have a form with lots of multiselect listboxes. All these listboxes have this.btcValArray as their rowsource. This array usually has two columns, the first is description and the second is a code. The number of rows in these arrays is ~10-20. I need to restore selections.
>
>Here is the current piece of code, which does it:
>

>for n = 1 to alen(.btcValArray, 1)	&& cycle over rows
>   if at(.btcValArray[m.n, 2], m.list_arg)>0   && this item is to be selected
>     .Container1.List1.selected(m.n) = .t. && flag list item as Selected
>   endif
>endfor

>
>list_arg is a comma-delimited list of codes.
>
>As you see, I'm looping through the array to set selected flag. This seems inefficient to me, if, say, I have only 2 items to mark as selected. There should be another way around... I'm wondering, if the optimization does make sense in this scenario and if yes, how would I optimize this code?
>
>
>Thanks in advance.