My replies scattered between yours.

"I think I should be able to look at a line of code and work out instantly what it is doing and if not then some comments would be nice. I think everyone should be able to work out what this code is doing in a few seconds but it really shouldn't take that long for such a simple operation."

Well I meant instant by saying few seconds. I didn't time glancing at two lines IOW. Anyone coding before the VFP6-7 days are accustomed to see that type of code and those type of lines do not need any commenting telling what it is doing clearly. It's like an "A" letter's shape is carved into your brain. I mean who needs to comment:

lcStr = FileToStr("myFile.txt")

That one was just longer for me:) I somewhat hate too much commenting cluttering the code and making harder to follow for me (whatever the comment says I explicitly check code myself). Yes, a personal thing like paranoia.

>
> I used to work with someone (he was my boss at the time but not anymore) who prided himself on being able to write really complicated code in one line, where people would take multiple lines for the same operation. He believed that this achievement made him better than the other coders when in fact everyone else hated debugging his code because it was so atrociously written. Never mind everything being bunched up, he also liked single letter variable names and PUBLIC variables abound and it made his code possibly the most hated in the company.



Good code seldomly needs debugging. I agree wholeheartedly on the use of public variables should be avoided.



>
> So I have a question. Would
>
>

> lnFifthComma = AT(",", fstr, 5)
> lnSixthComma = AT(",", fstr, 6)
> 
> reccnt = VAL(SUBSTR(fstr, lnSixthComma + 1, AT(",", fstr, 7) - lnSixthComma - 1)) + ;
>  VAL(SUBSTR(fstr, lnFifthComma + 1, lnSixthComma - lnFifthComma - 1)) 
> 

>
> actually be slightly faster than the original code because of the removal of the repeated calls? I am genuinely asking that question as I would be interested to know.
>

Yours might be faster but difference is negligible. It wouldn't gain more than a millisecond maybe in a single pass. But your code as the original one is prone to bugs hard to catch. You forgot to use mdot prefixes. Speed would be a concern if this code needs to be executed in a tight loop. Then there are faster ways:
-Using the mdot
-Instead of:

lnFifthComma = AT(",", fstr, 5)

store AT(",", fstr, 5) to m.lnFifthComma

-And probably you wouldn't believe the fastest way of parsing such strings is to use a listbox object. Unlike others parsing time is almost 0. However that would bring in readable code question. The code is tricky and would need experience to understand.

-For speeding up (remember in a tight loop, assuming we need it a lot of times) creating a cursor and appending might be simple, slick and fast. ie:

lcTemp = forcepath(sys(2015)+'.tmp', sys(2023))
strtofile(m.lcToParse, m.lcTemp)
create cursor myParser (f1 l,f2 l,f3 l,f4 l, f5 l, f6 i, f7 i)
append from (m.lcTemp) type delimited
erase (m.lcTemp)
select f6+f7 as reccnt from myParser

Actually I made a quick test now on my machine and this one did it in 5.918 seconds for 1Million lines string.


> Of course once GETWORDNUM became available to coders the snippet could have been rewritten as
>
>

> reccnt = VAL(GETWORDNUM(fstr, 7, ",")) + VAL(GETWORDNUM(fstr, 6, ","))
> 

>
> Much more readable AND fewer lines proving that improvements in VFP do allow us to improve ourselves.

Yes, GetWordNum() is much more readable. But beware if you are concerned about speed, it's slow.

Now the question is, more readable, commented or effective code I want - or all in one:)

Cetin Basoz