>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.

>>
>>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.

>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.

>>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.


>>And how about functions? Almost all functions have defaults for their parameters. But if you oppose the idea that pro's should know the defaults, then you probably also always specify the parameters anyway? And how is that done?

dimension ArrayName[1]
>>cFileSkeleton = curdir() && equals default
>>cAttribute    = ''       && equals default
>>nFlag         = 0        && equals default
>>nFound = ADIR( ArrayName, cFileSkeleton, cAttribute, nFlag )

>
>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.

>cheers