>>Peter,
>>
>>Pardon me for jumping in < s >...
>>
>>>>I have years of VFP experience and after a SQL SELECT you will see either a _TALLY or a SELECT to teh new cursor. You will also see a SELECT at the bottom of a scan loop right before the ENDSCAN. I am not a beginner, it makes the code easier to read.
>>>
>>>Not easier for me, though.
>>
>>You let little things bother you? You take something that makes code clearer and turn it into a grading of non-professional?
>
>As I said, it is not easier for me. You and Michael assume it makes code clearer, but I am challenging that assumption. Let us stop discussing the level of professionalism here. That's not the topic. The topic is whether or not it really is clearer.
>
PMFJI but..........
You've consistently said that seeing something like this (SELECT before ENDSCAN) makes you doubt the skill level of the programmer. That has been the topic for quite some time.

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?

>>>
>>>When do you use _tally? Always? Why and how? I use it sometimes, most notably if a result of zero records must be dealt with in a special manner. But in that case it's the functional design that forces me to use it, not merely a (useless) habit.
>>
>>Making code read clearer is not a "useless habit", but rather added "professionalism".
>>What does it hurt to store _TALLY after a SELECT-SQL in case it's helpful later (or even after othe DML commands)?
>
>Can you tell me how _TALLY is supposed to follow a sql-select?
>
>>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?


>
>>or to put ALL on the ScAN itself?
>
>No big deal. Is okay with me.
>
>>Do you also get upset with assigning LOCAL-defined variables with .F. at the beginning of a program?
>>If so, then I'd say you do let the wrong things bother you.
>
>As a matter of fact, declaring them anyway is preferable indeed. It indicates that the developer has not forgotten their declaration.
>
Aren't you contradicting yourself here? If LOCAL myVar automatically creates that variable and assigns it a value of .F., then, by your definition, assigning it that values shows a lack of understanding of the default behavior of LOCAL.


>>>Adding a SELECT at the bottom of an SCAN loop also implies that there is an additional line to recode (so, there's a maintenance issue here) if you change the alias name that is scanned. And why don't you also add a SELECT right after the SCAN command, to make things even 'clearer'?
>>
>>Weak. A poor justification to avoid making code clearer.
>
>No, the maintenance issue is a strong argument and not merely a justification.
>
>
>>Here's something else that I do that will probably drive you crazy (I don't do above unless I will be varying the parameters)...
>
>If you will be varying the parameters, then I don't see any problem. I was refering to a situation where parameters 2, 3 and 4 are not really used anyway.
>
>>When I define a multi-column array (typically only if more than 2 columns) I will code variable names with integer values (1, 2, 3,...) for the columns so that I can then refer to the columns by meaningful name rather than by a number.
>
>Useful and a good principle, in my opinion. Is not a 'defaults' issue, though.

Finally we have agreement on something. I don't do it as often as I should, but this is clearly a useful technique for improving readability.

>



>>cheers