>>You seem not to understand why LTR was invented in the first place. It was designed as a speed optimization in the days when computers were slow and expensive. To this day, that's its reason to exist. If you want to continue to use a side-effect of that optimization for flow control in your programs, do so at your own risk.
>
>LTR is not only for speed optimization. It can also help you avoid errors, while making code shorter.

We're probably splitting hairs here, but I maintain that the sole design purpose of LTR is as a speed optimization. This optimization has two related side-effects, those being:

- implied nesting of flow control constructs
- brevity/terseness of code

LTR, by itself, does nothing to help avoid errors. It's just a terser way to express error trapping code that you need to include one way or another.

>
>Here is a typical VFP construct:
>
>

>if type("SomeVariable") = "L" and SomeVariable
>  ...
>endif
>

>
>The possible error in this case is: SomeVariable doesn't exist, or has the wrong type. (If you think this is unlikely in your code, replace with some other condition that would cause an error.)
>
>Note that since VFP evaluates from LTR, the part after the AND will not be evaluated if the variable doesn't exist.
>
>Of course, this is completely equivalent to:
>
>

>if type("SomeVariable") = "L"
>  if SomeVariable
>    ...
>  endif
>endif
>

>
>but I personally like the shorter version, and I think LTR can be trusted in this case.

Clearly, the VFP docs guarantee consistency of LTR processing, as Sergey's link shows. If it had bugs, a lot of people would have found them and raised a big fuss.

My personal style leans more towards Jim's, especially when I'm trying to implement complex logic. In those cases, when I'm working from a truth table, using explicit flow control logic (IF...ELSE, sometimes CASE...) means that each cell of the truth table corresponds to exactly one code block. When # code blocks = # of cells in truth tables, I know I'm done. I also find it easier to locate the code block related to any given truth table cell, and for me debugging is simpler because I find it easier to set breakpoints, insert test code, or wrap existing code in other function calls as needed. If, later on, the logic needs to be changed, I update the truth table, then update existing blocks, add new ones, or delete as required, again with a visual 1:1 mapping.

But, everyone has their own idea on what is "readable" code - to each their own.

A side-effect of my not relying on LTR is that in languages, or parts of languages that don't, or improperly support LTR is that it doesn't affect me. From time to time, maybe it saves me from a day of frustration ;)