>>>In my opinion, writing code that's a little less efficient in places where it's okay to be less efficient, so long as the reason you're doing it is to be more clear for maintenance, shows signs of being a mature developer. You recognize that emphasis on speed needs to go where it needs to go, but not where it doesn't. In those places where it doesn't need to go you can use a better coding style, and that's the correct way to go.
>>>
>>>This is just my opinion, of course ... but I'm probably right. :-)
>>
>>I'm often maintaining other people's code. It's neither clear, nor fast, ever. Some of the things that were attempted were not for speed and resulted in the worst debugging issues.
>
>Most of the issues maintaining other people's code is either they're trying to do 'cute coding', as in "See how smart I am, I came up with this convoluted solution!"; or they're trying to follow the "this is the best way to do this NOW" model of coding.
>
>Granted, I've coded up with some ugly children in my time (and dressed them funny too), but 99% of them have a comment that reads "The following is ugly, but it works for the parameters given" with a list of the "are you kidding me?" requirements for that particular chunk of code.
>
>I discovered that FoxPro (and VFP) ran best under the KISS principle; besides, to quote Montgomery Scott "The more they overthink the plumbing, the easier it is to stop up the drain"

I'm not talking about overthinking the plumbing. Take this very thread for an example - all of the separate bits of coding are more verbose than the alines version. The alines version is insignificantly slower with 5 elements compared to getwordnum. It never occurred to me to use getwordnum, since I've known alines could beat getwordnum most of the time, and get better with larger data sets.

We are supposed to make small pieces of code that do their job cleanly, clearly and quickly, encapsulated into themselves (reusable, modular, with data all hidden). Having to use 2 different approaches to do the same work, when there is no significant difference between the 2 methods is ludicrous, because then you may be debugging the wrong function. 1 function that does 1 job as best as possible. Cars don't 2 spark plugs per cylinder, one spark plug for under 40 mph and a different one for above 40.

FUNCTION reverse_occurs_AT_mdot_unconditional
LPARAMETERS m.tcText
IF NOT ","$m.tcText
	RETURN m.tcText
ENDIF
LOCAL lnLines,lcRevString,lnStart,lnEnd, lnX
IF LEFT(m.tcText,2)#", "
	m.tcText=", "+m.tcText
ENDIF
lnLines=OCCURS(",",m.tcText)
lnStart=AT(",",m.tcText,m.lnLines)+2
lcRevString=SUBSTR(m.tcText,m.lnStart,LEN(m.tcText)-m.lnStart+1)
FOR m.lnx = m.lnLines-1 TO 1 STEP -1
	lnEnd=m.lnStart-2
	lnStart=AT(",",m.tcText,m.lnx)+2
	lcRevString=m.lcRevString+", "+SUBSTR(m.tcText,m.lnStart,m.lnEnd-m.lnStart)
ENDFOR m.lnx
RETURN m.lcRevString

This one finally works. I'm still open to improvements it might use. It's the most primitive approach, something that might have worked since occurs() first appeared. It matches getwordnum at smaller sets and beats getwordnum at larger sets, but it never beats alines. Does anyone think it wise to use all 3 ways in a single app depending on how many items? That is not engineering. That means have 3 times the code to maintain. That is not readable or maintainable.

The best way is to create a single function for this purpose. I also argue that function should be separately stored and separately checked in to source control, without any procedure library. Then when an exercise like this happens, you check out that one function (not the entire containing library) replace or tweak the code, and check it in. Done. KISS by definition.

Anyways, this has been fun. I still know to use alines.