>I understand what you're getting at, and that it's not quite the same as my example. But they are both examples of how source code can be formatted differently but still be interpreted the same way by the VFP command parser.

I suppose to a certain degree. I've done stuff like that to make it easier to move the lines around.

>
>What you're really arguing for is for everyone to adopt a consistent command syntax "style" (for want of a better word) - presumably, the one suggested in the VFP Help file - to improve readability. There's some value to that but I'm just arguing it shouldn't be dogmatic - there may be advantages to doing it another way.

Well, I wish I could find the reason in the code I've inherited.

>
>>Hi Al
>>
>>Not quite what I'm getting at.
>>
>>It's not so much about punctuation as reversing the phraseology.
>>
>>SELECT * FROM TABLE INTO CURSOR BLAH
>>
>>versus
>>
>>INTO CURSOR BLAH FROM TABLE SELECT *
>>
>>>I think one should keep an open mind. For example, in a recent message to me Fabio Lunardon used the following:

SELECT cFromIP ;
>>>	,	cPortProt ;
>>>	,	cToPDom ;
>>>	,	cToFDom ;
>>>	,	COUNT(*) counts ;
>>>INTO CURSOR GpTest1 ;
>>>		FROM Logs1;
>>>		GROUP BY 1,2,3,4

I don't know if Fabio purposely wanted tabs expanded out to 8 characters but that's not what's interesting here. I'd never before considered putting the comma for a list extension at the START of a new line, but it's thematic in the same way as:

* This
>>>
>>>m.lcSomeVariable = "SomeLongStringOrFunction1" ;
>>>  + "SomeLongStringOrFunction2" ;
>>>  + "SomeLongStringOrFunction3" ...
>>>
>>>* is preferable to
>>>
>>>m.lcSomeVariable = "SomeLongStringOrFunction1" + ;
>>>  "SomeLongStringOrFunction2" + ;
>>>  "SomeLongStringOrFunction3" ...