>Now as to whether or not it really is clearer.....It seems to be so for the programmers who do it. FWIW, count me as one of them. Granted that it started as a habit before I fully understood the SCAN - ENDSCAN construct. I continue to do it because it provides visual evidence to me of exactly where I am when I exit the loop. I find this especially useful when I have nested SCANS (the equivalent of ENDDO && loop condition) or when I have long code blocks and need a visual cue when checking the code below it.
>
>While it may not make the code clearer to you, how does it make the code LESS clear???? What is confusing about it that would make the code more difficult for you to maintain?

Since we all know that EndScan will re-select the alias it scans through, seeing a Select just above it would actually make me think "why does he do this? Is there any sideeffect of a Select which I didn't know of? What's the reason behind this?" etc.

I, for one, never look at the bottom of a scan/end block when I need to know which alias is being scanned. I go from the Scan statement up, to see what was the last alias selected.

>>>What does it hurt to put a SELECT before an ENDSCAN so that it is clear to **any** reader what is being done?...
>>
>>The maintainability of the code decreases and the risk of bugs increases.
>
>Again, HOW does it make the code less maintainable and what possible bug could be introduced? The nano-seconds (if that) of execution time?

Maybe it's when the scan's alias is changed upstream. For instance, we used to Scan For through our table, but now have a cursor derived from it... and then we also have to remember to select the new alias at the end of the loop, where it still says Select MyTable. That's one more thing to maintain, and IMO, without a good reason.