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

Sure, that's fine with me. I only mentioned it because you originally brought it up.

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

I don't do that as a matter of course myself, but I'm now considering doing so after it was mentioned.
As you know, _TALLY tells you how many records were selected (or affected in the case of other commands). As you also know, _TALLY will be changed the next time any "table command" is executed.
When you select INTO an array or TO anything you have no other practical and safe way of knowing how many records were affected/created other than by inspecting _TALLY. Particularly relevant for INTO array because there will be no array if no records were selected. Keeping the returned _TALLY value in a memvar is a smart thing to do. In fact I can argue that it simplifies maintenance because you can change your destination with less impact on other code.

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

In an era of FIND/REPLACE and mouse scroll wheels this is a weak argument at best. In the meantime the reader gets a nice reminder of which area is current. For any reader to be bothered by that is, to me, surprising.

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

Ah, but you contradict yourself because all locals DEFAULT to .F. So what we have is discretionary "standards". Funny, but that's what I'm talking about too.

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

As I said earlier, with FIND/REPLACE and mouse scroll wheels it is a very weak argument. I acknowledge it would add another 1.5 seconds maintenance time or so per SCAN, but the reminder in the code is far more valuable in the long run.

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

Agreed that it is not a 'defaults' issue. But it does add to coding and theoretically to the maintenance difficulties, so I guess many readers would have a problem with it.

This all started, Peter, based on a statement I made regarding "refactoring" and the danger that much refactoring will become justified solely on the basis of the coding style being deemed crappy by the new maintainer.
And I tried to suggest that even my coding style, which I'm quite sure would be found wanting by many readers, is not itself justification for refactoring.
I still consider that taking the minorly extra time to code the "extraneous" things I code is helpful to the next reader. Else I wouldn't be doing them.

cheers

>
>>cheers