Hi Al

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

Fair enough. Section 1 is my wish to keep this discussion out of "religious" mode.

>
>*** 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'm referring to programming style. I'm perfectly willing to consider changing my current style, if someone can convince me of a better way. I have changed my style to match others' styles on several occasions. If we all refuse to leave this possibility open, there is little point to continuing the discussion of standards.

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

I've asked for opinions on possible improvements to my routines. In every instance, this board has provided a better version of my routine. Keeping an open mind as to the possibility that a better way exists, should help this discussion move forward. I'm leaving room for the possibility that your approach is better than mine.

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

That is a matter of opinion. I want more value, yet I hear the argument that today's computers are so fast that speed is not significant too often.

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

Yes, to a certain extent. But striving for as much of all of these as possible is worthwile.

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

Agreed. I'll keep that in mind.

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

That was all well written. Lazy was a poorly chosen word. I've seen slow code result from what seems to be a just get it done attitude. I've also seen it result from just not thinking the problem through. Instead of lazy, I should have said it seems it comes from a lack of interest in getting it done *well*.

I have seen many situations where evolution has not taken place.

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

You did put a wink after saying they are both bad. I interpreted the wink as indicating you were joking. Since you were serious, we have a communication problem. I did say I was guessing, which you seem to have taken as "consider my opinion a joke".

This touches on what I was trying to say in section one. I'm trying to keep an open mind. I will try not to get personally involved and take offence. I'm trying to keep my personal preferences out of this discussion and use other criteria to evaluate different approaches. I deliberately chose not to use the word style. There is, as the saying goes, no accounting for taste, and apparently, style.

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

Thank you <g>.

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

I wouldn't call this my approach. I didn't invent FOR...NEXT ;).

I agree that "your approach" now says the loop will run to a maximum of ten if it doesn't end early. However, I have to read two lines of code to see the start and end values.

Perhaps this can be dealt with by ...

DO WHILE m.x >=1 AND m.x<=10 AND NOT m.llDoneEarly

The FOR NEXT construct supports an EXIT. It should be recognized that an early exit is always possible.

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

Hmmmm. That is an interesting point. However, I can determine that FOR NEXT also has ended early by comparing the highest value of x with the maximum value of x. I admit this requires either ...

FOR x = 1 TO 1000
  IF x = 10
    llDoneEarly = .T.
    EXIT
  ENDIF
ENDFOR
?m.x

OR

FOR x = 1 TO 1000
  IF x = 10
    EXIT
  ENDIF
ENDFOR
m.llDoneEarly = (m.x <> 1000)

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

There is that significance argument. I'm trying for as much value as possible. If one approach meets more of the readable-maintainable-speed criteria than another, I want to use that approach.

You have to write code to create and update x, where the for next takes care of that. That leaves more code to test, and possibly room for more bugs. It is a fact that executing a line of code takes time.

Why do we need real-world tests? Do other disciplines not test things in labs to see if they will be able to move into the real world? If we are to create real-world tests, shall we use code from my current project? Do I then have to give you my client's data to prove one approach is faster than another. That is not possible. So we're back to the lab, but you suggest that is not reliable.

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

Agreed.

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

It is documented that FOR NEXT/ENDFOR should be used when the number of iterations is known in advance. Do you suggest using DO WHILE for everything and never using FOR NEXT/ENDFOR and that this be a standard?

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

What do we use as the title for this? Use DO WHILE, never FOR NEXT?

Many interesting points. Thank you for taking the time to discuss this!