Hi Mike,

An interesting post. I'm going to divide it into 1st and 2nd halves because I can't see how they're related.

*** SECTION 1 ***
>Hi Al
>
>I think we'd all do better to remove style from such discussions.

I don't know what you mean by "style" - programming style (isn't the whole thread about this?) or posting style? If the latter, do you have a specific complaint?

>I also think we'd do better to approach this with the belief that someone certainly has a better way to do things.

I don't know what you're getting at here, but if we take this literally it's not true. In some things it can be proven there is an optimal solution which can't be improved further. Take linear programming in mathematics, for example.

>Further, let's pretend we're electronic engineers. That way if we do something weird, the circuit may work, or it may burn up after a while, or the relay may click too slowly.

I'm an ME so I have a natural aversion to pretending to be an EE < vbg >, but okaaaaaaaay...

>
>It used to be we'd try to be efficient, now we're letting faster computers make us lazy.

It's not true of me. You're casting aspersions on the practitioners of this profession.

>We cannot know what machine the user may have.

No, but we can specify a minimum machine the user must have to run our software with acceptable performance. This is standard practice.

>We can be certain our code is the best it can be. Is that not the very purpose of the UT?

Although I said above that some tasks may be provably optimized, software development, except for the most trivial of examples, is not one of them. How can you know your code is the "best it can be"? Best performance? Fewest bugs? Most maintainable? To a certain extent, these are mutually exclusive. And in the general case, if we can apply more resources, our code will get better.

As professionals, what we *can* do is to improve our skills so in general, we can produce better code for a given budget. And yes, the UT is helpful in this.

>Just remember everytime you use a commercial Piece Of Software ;) and find it slow, it's because someone got lazy.

I don't accept this at all. Some reasons software can be slow:

- The task is inherently hard. Speech recognition, for example.
- Insufficient resources allocated to the entire project. This will result in sub-optimal code in one or more modules, or more seriously, in sub-optimal design, which is likely to affect the performance of the entire application.
- Poor project management. Even if sufficient resources are allocated overall, imbalances can mean that critical parts are starved.

Any of the above can happen with 100% non-lazy personnel. Lacking in skills, maybe, but not lazy. I believe most software developers are hard-working professionals and that most "slow" software is caused by the reasons above.

There may be a *small* category of software where the author(s) are "lazy" - I can only assume you're referring to unprofessional behaviour. If that's the case the problems are likely to be bigger than just speed - reliability, support, breach of contract, for example - and any such should be be weeded out by the free market in due course. Evolution in action.

*** SECTION 2 ***

>>>You're not saying that

FOR x = 1 TO 10
>>>    ...some code
>>>    x = 11
>>>    ...some more code
>>>NEXT x

>>>is better than

FOR x = 1 TO 10
>>>    ...some code
>>>    EXIT
>>>    ...some more code
>>>NEXT x

are you?
>>
>>No, they're both bad ;-)

llDone = .F.
>>x = 1
>>
>>DO WHILE x < 11 AND NOT llDone
>>  ...some code
>>  * Set llDone appropriately
>>
>>  x = x + 1
>>
>>ENDDO

>
>I'm guessing you were kidding. Would a discussion of the reasons why this example might be used as a joke be OK?

No, I wasn't kidding and I'll try to forget you consider my opinion a joke. My code above reformulated slightly below, followed by further discussion.

m.llDoneEarly = .F.
m.x = 1

DO WHILE m.x <= 10 AND NOT m.llDoneEarly
  ...some code
  * Set m.llDoneEarly appropriately

  m.x = m.x + 1

ENDDO

>How about a list of conditions that should support a standard. Clarity/maintainable, efficiency,
>
>Clarity: I believe it is slightly confusing, because "< 11" isn't as clear as "= 10".

OK, now changed to "< = 10".

>FOR X = 1 TO 10 clearly indicates the range of the loop.

The problem I have with this whole FOR approach is that the first, defining line is a lie. The FOR statement says the loop will be executed 10 times. Really, the loop is going to be executed 10 times unless it's finished early. Your approach lies by omission; mine is crystal-clear, explicitly alerting the reader to watch out for special conditions later in the code.

>Efficiency: The m.llDone variable requires extra code to create and update.

To create the variable, yes. To update, maybe not:

* Within the loop:
* Your way:
IF SomeLogicalCondition()
  EXIT

ENDIF

* My way:
m.llDoneEarly = SomeLogicalCondition()

One advantage to having the variable is in debugging and future code enhancement. At the end of the loop you can find out if it went the whole distance or if it finished early. In my real life code I find I need this kind of information *all the time*.

>The use of the do while...enddo versus the for...endfor involves an extra line x = m.x + 1. x would have to be declared as 1 before the loop.

The FOR loop has to declare, initialize, and increment the x variable as well. It might be more efficient in doing so, but if so, how much? Is it significant? We'd need real-world tests to tell for sure. I've been surprised by test results too often to rely on theoretical discussions on how anyone thinks VFP *should* work anymore.

>m.llDone clearly indicates the routine is done. It doesn't indicate the routine abended. Adding m.llAbended may be valid if it is included for the same reason as m.llDone. If on the other hand we can say it is nonsense to add m.llAbended, it may be argued we should not include m.llDone either.

I think this semantic issue is addressed by renaming it to llDoneEarly as in the amended example. And its value persists outside the loop with the benefits listed above.

>IMO, Jim's second example is best, because it has no extraneous code to reduce clarity or efficiency.

IMO it's better than the first, but mine is better than either.

>One other point. We're proposing standards, but how/where can we write them up. The wiki is good, since it allows edits.

Agreed.